search

PhoenicisOrg / scripts

Phoenicis scripts
GNU Lesser General Public License v3.0
64 stars 49 forks source link

Alternative approach to #841 #855

Closed Kreyren closed 5 years ago

Kreyren commented 5 years ago

Ok as @plata said, this is not the right place to discuss about this.

What you are describing is just not as magick and simple as you tend to describe it. You are really underestimating the differences between the distributions and the amount of bug report we are going to receive.

Originally posted by @qparis in https://github.com/PhoenicisOrg/scripts/issues/841#issuecomment-460033522

You are really underestimating the differences between the distributions and the amount of bug report we are going to receive.

I would just introduce the feature and allow downstream to deal with compatibility alike if distro is missing compiler -> disable compiling feature

meaning if distro uses precompiled -> using compiled is meaningless and shoudn't be used.

for runtime we practically need a way to cherrypick needed dlls or output error (WINEDEBUG="+dll") for end-user to fix the issue alike install package with required dll + if dll is broken -> update it.

i can't imagine different issues?

ImperatorS79 commented 5 years ago

@Keyren if it does not bother you, I think this should be closed in favour of https://github.com/PhoenicisOrg/phoenicis-winebuild/issues/62

Kreyren commented 5 years ago

@ImperatorS79 Nope the decision is up to you, assuming that i'm trying to provide alternative POV on the issue and solution.

disclaimer: no passive agression intended

EDIT: probably should be debate tho..

ImperatorS79 commented 5 years ago

I just wanted to move the discussion to avoid having to much issue speaking about the same thing, no worries ^^.

Kreyren commented 5 years ago

@ImperatorS79 Seems irelevant considering that https://github.com/PhoenicisOrg/phoenicis-winebuild/issues/62 proposes different solution to present issue?

Assuming that i'm for compiling wine and issue above suggest proving libs precompiled?

qparis commented 5 years ago

I don’t understand what this issue is about in fact. The title and the content are not clear enough

Kreyren commented 5 years ago

@qparis seems streit forward to me.. alternative approach to provide wine engine including it's libraries in phoenicis?

qparis commented 5 years ago

Normal that it is straightforward to you because you wrote the ticket. There are no straightforward alternative to provide wine binaries

Kreyren commented 5 years ago

@qparis i see what do you mean.. my fault

My approach would be to allow users to deal with WINE alike:

Using compiled WINE

Rolling distros are made to use compiled wine simply using javascript to invoke emerge or pacman as root is sufficient to get WINE working on those distros.

Refferences on https://github.com/PhoenicisOrg/scripts/issues/841#issuecomment-460033522 of using system wine.

Providing compiler for WINE in phoenicis for distros that don't have compiler like ~EndlessOS~ SuperLimitedOS

The benefit of providing compiler is that this feature would be supported on distros like EndlessOS that are provided without compiler using flatpak only.

@qparis You said there are other issues with this implementation that i find hard to imagine..

From my POV we have a critical bug that makes most scripts in Phoenicis as unusable and i'm offering solution that is resource friendly and maintainance-free + which offers more methods for contribution..

qparis commented 5 years ago

Ok, please read my comments because I have the feeling that I'm repeating the same things over and over, so:

Using compiled WINE

Rolling distros are made to use compiled wine simply using javascript to invoke emerge or pacman as root is sufficient to get WINE working on those distros.

* _0 maintainance for phoenicis_
* preffered way to handle WINE by rolling user distros,
* Solves conflicts with dependencies
* Solves proves all WINE bugs, regressions, etc..
* Allows more effective development for phoenicis contributors and winehackers

Refferences on #841 (comment) of using system wine.

As I said (and repeated) before, this is almost impossible to maintain:

So your proposal does not solve any problem, in fact, it creates more problem. You are just deporting the problems of fetching the right version of wine dependencies to the a new problem (fetching the right version of wine itself).

Providing compiler for WINE in phoenicis for distros that don't have compiler like EndlessOS SuperLimitedOS

* Allows compiling WINE on distros that doesn't support it.
* Solves problem with dependencies
* Depending on the implementation 0 maintainance for phoenicis
* Shoudn't be taken with high-priority
* * Advantages of USING compiled WINE

It does not solve dependencies problems at all... Instead of dealing with runtime dependencies, you now need to deal with compiling time dependencies. Why do you think phoenicis-winebuild needs to set-up a complex docker stack to provide binaries if it is that simple to create a script that builds wine correctly with all the dependencies? So again, it does not solve anything. On the contrary, it creates even more problems.

From my POV we have a critical bug that makes most scripts in Phoenicis as unusable [...]

What critical bug? We just need to provide the right runtime and there won't be any problem.

and i'm offering solution that is resource friendly and maintainance-free + which offers more methods for contribution..

The maintenance cost is very huge. From your POV, you are happy if we make things working on Gentoo. And of course it is simple to create a script that works with ebuild for each game. Now, imagine that we have thousand of games and apps that we are going to have to match with hundreds of distributions. The number of combination is just exploding.

Kreyren commented 5 years ago

There are 100+ ways of installing wine (pacman, dpkg, emerge, pkg_add, yum, etc...), so you would need to detect each possible distribution and to watch for all distribution upgrades to ensure that the scripts uses the rights commands.

Disagree assuming that the script would be maintained for each distro (if needed) by script maintainers, community and contributors + maintainance of it shoudn't be relevant for us considering that my POV is that phoenicis should focus only on providing platform and tools to configure engine.

No need to say that it would be a nightmare to maintain (and I choose my words carefully). So when you say 0 maintainance for phoenicis, I really cannot agree with that.

I'm talking about adding a feature that won't use phoenicis's WINE on demand.. nothing else is needed..

This would not be a solution to wine regressions because let's say we found a 100% efficient way of doing this (this is just thought experiment, as I said before it is impossible). We cannot guess what version is going to be installed by the user. Therefore, let's say we need the version 3.1.9 because we know that wine 3.1.10 has a regresion that breaks a given game, it is hardly impossible to do.

You are spoon-feeding the users this approach is for experienced users who knows how to use their system. Maintainance from phoenicis to ensure that it's working is NOT expected. Is preffered to let those users handle their WINE invidually.

For example Gentoo is built on this concept.. Arch simmilar, Debian Sid simmilar, LFS is on whole new level with this concept.. + Script maintainers can always do something alike https://github.com/RXT067/Scripts/blob/d39f751d56fe8b6d325fe5a0c98c26c715930a1b/KUWAC/CONFIGURATION/LeagueOfLegends.sh#L5 to ensure that correct configuration is made..

It does not solve dependencies problems at all... Instead of dealing with runtime dependencies, you now need to deal with compiling time dependencies. Why do you think phoenicis-winebuild needs to set-up a complex docker stack to provide binaries if it is that simple to create a script that builds wine correctly with all the dependencies? So again, it does not solve anything. On the contrary, it creates even more problems.

Agreed that it would cause more problems and shoudn't be prioritized atm. Is meant to be considered when phoenicis is in gold and based on feedback from the community assuming that there will be issues with pre-compiled wine.

What critical bug? We just need to provide the right runtime and there won't be any problem.

Seems critical to me considering that it breaks the only engine that phoenicis currently has..

The maintenance cost is very huge. From your POV, you are happy if we make things working on Gentoo. And of course it is simple to create a script that works with ebuild for each game.

It's VERY VERY far from beeing simple to make an ebuild for each game.. https://github.com/RXT067/KGGO/blob/master/games-moba/leagueoflegends/leagueoflegends-4933455.ebuild Considering that portage doesn't have wine.eclass or supports invoking wine as non-root (https://bugs.gentoo.org/show_bug.cgi?id=673888). This feature is theoretically and practically impossible, but i've still did it and it works like a charm.. excluding that it can invoke something like a wannacry.. This is not even an ebuild it's just workaround for workarounds.. Probably abusing bugs in portage..

Now, imagine that we have thousand of games and apps that we are going to have to match with hundreds of distributions. The number of combination is just exploding.

That is expected assuming that effective method for contributors to make scripts and maintain them is in place. We don't need to ensure that the scripts are working we just need to mark them as "NOT WORKING" and let contributors (me included) deal with it..The more effective you make the implementation -> more script can be produced.

Going with this approach since it's from my POV the only way to keep all scripts updated assuming that phoenicis currently provides scripts that are broken which from my POV was deal breaker for me on PlayOnLinux 4 which i would still prefer if method to provide scripts was implemented better and assuming that phoenicis is unable to maintain all scripts and ensure their quality and functionality..

Kreyren commented 5 years ago

btw. I'm sorry if i missrepresent the issue.

qparis commented 5 years ago

There are 100+ ways of installing wine (pacman, dpkg, emerge, pkg_add, yum, etc...), so you would need to detect each possible distribution and to watch for all distribution upgrades to ensure that the scripts uses the rights commands.

Disagree assuming that the script would be maintained for each distro (if needed) by script maintainers, community and contributors + maintainance of it shoudn't be relevant for us considering that my POV is that phoenicis should focus only on providing platform and tools to configure engine.

You are supposing that you will always have script mainteners per distro that are going to update the scripts directly. This is utopian. Just count the number of POLv4 scripts that still use wine 1.4 to 1.7 because of the lack of maintenance and convince yourself.

No need to say that it would be a nightmare to maintain (and I choose my words carefully). So when you say 0 maintainance for phoenicis, I really cannot agree with that.

I'm talking about adding a feature that won't use phoenicis's WINE on demand.. nothing else is needed..

Except that if you provide a feature, you also need to provide support for this feature.

This would not be a solution to wine regressions because let's say we found a 100% efficient way of doing this (this is just thought experiment, as I said before it is impossible). We cannot guess what version is going to be installed by the user. Therefore, let's say we need the version 3.1.9 because we know that wine 3.1.10 has a regresion that breaks a given game, it is hardly impossible to do.

You are spoon-feeding the users this approach is for experienced users who knows how to use their system. Maintainance from phoenicis to ensure that it's working is NOT expected. Is preffered to let those users handle their WINE invidually.

Same again. If you provide a feature, you provide support. That is the rule. Also, the main target of phoenicis are defintely not advanced users.

For example Gentoo is built on this concept.. Arch simmilar, Debian Sid simmilar, LFS is on whole new level with this concept.. + Script maintainers can always do something alike https://github.com/RXT067/Scripts/blob/d39f751d56fe8b6d325fe5a0c98c26c715930a1b/KUWAC/CONFIGURATION/LeagueOfLegends.sh#L5 to ensure that correct configuration is made..

I can guarantee that your script will fail 95% of the cases today, and 99.9% of the cases tomorrow. So again, it does not provide any solution

It does not solve dependencies problems at all... Instead of dealing with runtime dependencies, you now need to deal with compiling time dependencies. Why do you think phoenicis-winebuild needs to set-up a complex docker stack to provide binaries if it is that simple to create a script that builds wine correctly with all the dependencies? So again, it does not solve anything. On the contrary, it creates even more problems.

Agreed that it would cause more problems and shoudn't be prioritized atm. Is meant to be considered when phoenicis is in gold and based on feedback from the community assuming that there will be issues with pre-compiled wine.

When it is the case, I do not see any reason to add this features. Why brining problems if everything works fine?

What critical bug? We just need to provide the right runtime and there won't be any problem.

Seems critical to me considering that it breaks the only engine that phoenicis currently has..

It does not if wine and its dependencies are installed system side. We can even improve the solution. by ontributing to phoenicis-winebuild.

The maintenance cost is very huge. From your POV, you are happy if we make things working on Gentoo. And of course it is simple to create a script that works with ebuild for each game.

It's VERY VERY far from beeing simple to make an ebuild for each game.. https://github.com/RXT067/KGGO/blob/master/games-moba/leagueoflegends/leagueoflegends-4933455.ebuild Considering that portage doesn't have wine.eclass or supports invoking wine as non-root (https://bugs.gentoo.org/show_bug.cgi?id=673888). This feature is theoretically and practically impossible, but i've still did it and it works like a charm.. excluding that it can invoke something like a wannacry.. This is not even an ebuild it's just workaround for workarounds.. Probably abusing bugs in portage..

Now, imagine that we have thousand of games and apps that we are going to have to match with hundreds of distributions. The number of combination is just exploding.

That is expected assuming that effective method for contributors to make scripts and maintain them is in place. We don't need to ensure that the scripts are working we just need to mark them as "NOT WORKING" and let contributors (me included) deal with it..The more effective you make the implementation -> more script can be produced.

And how do you know that they are not working? Suppose that your script work one day, how do you detect when it is broken?

Going with this approach since it's from my POV the only way to keep all scripts updated assuming that phoenicis currently provides scripts that are broken which from my POV was deal breaker for me on PlayOnLinux 4 which i would still prefer if method to provide scripts was implemented better and assuming that phoenicis is unable to maintain all scripts and ensure their quality and functionality..

To conclude: You tend to forget is that it is not hard to fix a script when we detect that it is broken. What is hard is to know precisely what script or group of is broken. Factoring the code using installer templates is a way to drastically reduce the number of combinations from POLv4 to POLv5. This is almost impossible in bash, this is way we want from Bash to JS. It will certainly help us to test and fix many scripts at once. What your are proposing is the exact contrary and will lead to an explosion of script numbers (N = NUMBER_OF_DISTRO NUMBER_OF_GAMES_AND_APP NUMBER_OF_SCRIPT_VERSIONS ~= 30000 in your cases without taking macOS into account)

madoar commented 5 years ago

There is another issue with using wine from your system package manager:

Additionally I don't see how the benefits of compiling wine directly on the user side are greater than the benefits of providing a precompiled version of wine.

What we could think about is that we allow using system wine. (like POL4 does if I remember correctly)

Kreyren commented 5 years ago

@qparis

You are supposing that you will always have script mainteners per distro that are going to update the scripts directly. This is utopian. Just count the number of POLv4 scripts that still use wine 1.4 to 1.7 because of the lack of maintenance and convince yourself.

I'm sorry for saying this, but from my point of view POL4 is unfinished garbage that lacks community, guidaince, Quality assurance, Acceptable documentation, core+mandatory functionality and the way it handles funtions .. that's why it doesn't have people that are making scripts on it based on my personal experience..

Simmilar applied to lutris

Simmilar appliet to winepak

The only utopia about this is to make a working implementation by the developers of those compatibility layer managers for example:

Assuming that I know that i need vcrun2017 and adobeair on winxp using wine-3.18 with staging for distro X ..

For phoenicis you expect me to know java, javascript fix issues that are phoenicis specific etc.. etc.. How does exactly someone who knows nothing about phoenicis, but knows correct configuration supposed to contribute?

for POL4 You expect end-user to know bash which is acceptable, but you are using lots of unique funtions that require time investment to learn.. Who in the right mind would want to do that when he/she can use lutris which is supperior to POL4? Alike Blizzard made OverWatch Configuration for it..

for Lutris Maintainers are supporting ubuntu only, its full of bugs, lacks required features and community is full of kids and toxic..

for Winepak (based on experience from yesterday) is abadonware and implementation is not ideall + lacks required features to generate a community.

Ideally phoenicis/POL4 would have GUI that manages BASIC engines configuration on demand and then exports configuration used in phoenicis to be used by anyone on demand with a the ability to leave comments, votes, tag it for specific distros (which is already possible in script.json) and so on based on user-feedback supported by multiple communities full of people providing feedback to educate the community, provide quality assurance, info required for research to know what works and what does not.

Ideally this would be build on POL4 which uses BASH and python which are the first scripting and first programming language that person learns on linux.. I personally see no reason for java nor javascript for WINE since i believe that object oriented programing from https://github.com/PhoenicisOrg/phoenicis/issues/1787#issuecomment-455862629 is not needed considering that i can make supperior configuration for gentoo using simple bash script on https://github.com/RXT067/Scripts/tree/master/KUWAC.. but i would agree that using python might also be a pita for upstream..

Except that if you provide a feature, you also need to provide support for this feature.

For my usecase of using system wine You are NOT expected to provide support for such feature assuming that it's wine problem which can be provided by community not upstream. Maintainance assuming reproducable bug is expected which should be minimal..

Generaly yes, but we are in linux you can give people blank file and to build a linux distro of it and run it on toaster or they tell you that you are terrible and switch on ubuntu..

Same again. If you provide a feature, you provide support. That is the rule. Also, the main target of phoenicis are defintely not advanced users.

Rules = Proprietary Do whatever you want = FOSS (usually self-regulates into ethical codex or code of conduct)

I can guarantee that your script will fail 95% of the cases today, and 99.9% of the cases tomorrow. So again, it does not provide any solution

I can guarantee you that this script is going to work on 100% cases on Gentoo.. using explained concept above and that i'm motivated enough to finish it..

When it is the case, I do not see any reason to add this features. Why brining problems if everything works fine?

is meant to be used as a concept depending on the situation at hand to fix problem with engines dependencies automatically and exclude required maintainance for them and way to provide them. Not needed atm, sharing it since i believe that it's going to be a problem in the future based on my own experience.

It does not if wine and its dependencies are installed system side. We can even improve the solution. by ontributing to phoenicis-winebuild.

from my POV it's pratically impossible from contributor's side, but fair enough.

And how do you know that they are not working? Suppose that your script work one day, how do you detect when it is broken?

https://github.com/Kreyren/KreyOverlay/blob/be1b9e566dce00d489333426e32621b6bb872f0e/games-util/.phoenicis/phoenicis-5.0_alpha2.ebuild#L83 Basic quality assurance, approch open-minded and exclude user-confusing in github tracker by making errors that provide all required info for example..

To conclude: You tend to forget is that it is not hard to fix a script when we detect that it is broken. What is hard is to know precisely what script or group of is broken. Factoring the code using installer templates is a way to drastically reduce the number of combinations from POLv4 to POLv5. This is almost impossible in bash, this is way we want from Bash to JS.

Depending on the implementation.. what is hard on invoking WINEPREFIX="something" winetricks dep1 dep2 dep3 && WINEPREFIX="something" WINEDEBUG="-all" wine executable.exe ? That is practically basic configuration needed for WINE engine which can be generated using GUI and user with hammer to press buttons on keyboard..

It will certainly help us to test and fix many scripts at once. What your are proposing is the exact contrary and will lead to an explosion of script numbers (N = NUMBER_OF_DISTRO NUMBER_OF_GAMES_AND_APP NUMBER_OF_SCRIPT_VERSIONS ~= 30000 in your cases without taking macOS into account)

That is expected assuming that it would be self-regulated. Practically basic concept of linux yes you are going to get spammed with scripts at the cost of quality that eventually results in pure quality..

This can also be made more efficient using predefined Code Of Conduct to make sure we won't get Debian veterans telling you that earth is flat

@madoar

There is another issue with using wine from your system package manager:

  • you normally have only a single wine version available

On gentoo you have all wine versions including all patches and configuration in bobwya overlay..

On arch i was told it's simmilar

On ubuntu,etc.. yes that might be problematic, but its not expected to be used for those distros..

  • it is often quite an old version (for example my I have version 1.6.2 available according to apt-cache show wine)

I'm on ubuntu since my main system broke softwarewise it has WINE-4.1 from winehq-staging atm.. Update sources.list and run aptfu..

yes proclematic, but not expected to be used on those distros

EDIT: Basic wine configuration assuming that it can be tweaked on demand after the fact and exported.

Kreyren commented 5 years ago

Sorry for long message, i believe that it's important to provide this info.

qparis commented 5 years ago

PlayOnLinux has been existing for 11 years and the number of contribution is larger than you imagine. We made some mistakes, but not the one you are mentioning. The documentation is more than complete.

We’ve had more than ten years to take hindsight and you don’t trust our experience. I don’t know what else I can say.

madoar commented 5 years ago

For phoenicis you expect me to know java, javascript fix issues that are phoenicis specific etc.. etc.. How does exactly someone who knows nothing about phoenicis, but knows correct configuration supposed to contribute?

I don't really understand how this is a problem? Phoenicis is a platform, which provides a certain number of ways to interact with it (an UI and a Script interface). To use Phoenicis you need to understand how you can interact with it, as a normal user you need to understand the UI, as someone wanting to provide support for an application you need to understand the Script interface.

This is the same with every platform. Let's take Linux itself as an example. If you want to use Linux you need to understand its UI and if you want to dig deeper you need to understand other interfaces like Bash.

Ideally this would be build on POL4 which uses BASH and python which are the first scripting and first programming language that person learns on linux.. I personally see no reason for java nor javascript for WINE since i believe that object oriented programing from PhoenicisOrg/phoenicis#1787 (comment) is not needed considering that i can make supperior configuration for gentoo using simple bash script on https://github.com/RXT067/Scripts/tree/master/KUWAC.. but i would agree that using python might also be a pita for upstream..

I'm not sure how to comment here:

For my usecase of using system wine You are NOT expected to provide support for such feature assuming that it's wine problem which can be provided by community not upstream. Maintainance assuming reproducable bug is expected which should be minimal..

This solution would possibly take forever until a fix is introduced in your distibution. First you need to wait until the bug is fixed in wine. Then you need to wait until the fix is added to your system package. A lot of systems also perform a package freeze, which could prevent the fix being added at all.

Generaly yes, but we are in linux you can give people blank file and to build a linux distro of it and run it on toaster or they tell you that you are terrible and switch on ubuntu..

We are not planning to write a linux only application. Currently we also support OSX. In the future we're also thinking about supporting Android. Therefore we can't limit our scope to linux only. Please be aware that this increases the complexity when building wine for multiple platforms by a lot.

On gentoo you have all wine versions including all patches and configuration in bobwya overlay.. On arch i was told it's simmilar On ubuntu,etc.. yes that might be problematic, but its not expected to be used for those distros..

I'm using an Ubuntu based system and together with me a lot of other users too. I would also go so far and say that a large part of the PlayOnLinux users use Ubuntu compared to Gentoo and other Linux distributions.

I'm on ubuntu since my main system broke softwarewise it has WINE-4.1 from winehq-staging atm.. Update sources.list and run aptfu..

Yes but do you think it is a good idea to force users of Phoenicis to add an additional repository? Especially if they require their previous wine version for other applications. In addition it makes it difficult to use multiple different wine installations at the same time.

Kreyren commented 5 years ago

We’ve had more than ten years to take hindsight and you don’t trust our experience. I don’t know what else I can say.

i'm not saying that i don't.. frankly i woudn't been there if i woudn't trust it..

For phoenicis you expect me to know java, javascript fix issues that are phoenicis specific etc.. etc.. How does exactly someone who knows nothing about phoenicis, but knows correct configuration supposed to contribute?

I don't really understand how this is a problem? Phoenicis is a platform, which provides a certain number of ways to interact with it (an UI and a Script interface). To use Phoenicis you need to understand how you can interact with it, as a normal user you need to understand the UI, as someone wanting to provide support for an application you need to understand the Script interface.

Why do we discard people who knows nothing about programming assuming that script can be maintained UI only? That should be our selling point alike test it, if it works publish it and read feedback.. this is not rocket science just cherrypicking variables..

This is the same with every platform. Let's take Linux itself as an example. If you want to use Linux you need to understand its UI and if you want to dig deeper you need to understand other interfaces like Bash.

No you dont lol? That's why ubuntu or windows are so popular.. and that's what i'm suggesting.. to make the script development so intuitive that little kid can do that -> More maintainers -> more scripts -> more people motivated to maintain them -> more quality assurance -> more working scripts.. + optionally using handmade scripts..

  • I don't agree that BASH and Python being the first scripting languages that people learn. This depends on the person and his or her background. Also, please don't forget that a lot of people didn't start with Linux but on Windows (me included). I started programming with PHP and a little bit of JavaScript followed by Java.

Fair enough.. My point was that learning bash and python is more intuitive for linux user (considering that it's practically using terminal written down) then learning java which is generaly used by less people..

  • About using bash scripts for configurations: This is contrary to your previous issue with POL4, that it takes so much time to learn the different parameters/functions.

well depends we can always just invoke bash script in POL terminal.. + suggestion above to educate the community is sufficient for this usage..

  • Object oriented programming helps with understanding the code and structuring the code. In our case I also think it helps with validating and testing the scripts. I'm not sure how well this can be done with bash scripts

well as provided above we can make an error message for each line if needed and you can do a lot of things in bash... practically we can build a whole linux distro on bash including package manager like LFS is doing.. Ideally script maintainer would decide how to write the code and we should provide a good documentation for all used functions to interact with GUI. i would even go as far as to deprecate javascript scripts for reasons above not sure if it's sane for current development of phoenicis..

again we are cherrypicking variables not programming a rocket..

This solution would possibly take forever until a fix is introduced in your distibution. First you need to wait until the bug is fixed in wine. Then you need to wait until the fix is added to your system package. A lot of systems also perform a package freeze, which could prevent the fix being added at all.

Again not meant to be used on distros like ubuntu.. Saying that it's practically mandatory on Rolling distros since they usually use versions close to master (if not master) which may require different libs, etc.. and that it's preffered way to handle WINE on those distros..

We are not planning to write a linux only application. Currently we also support OSX. In the future we're also thinking about supporting Android. Therefore we can't limit our scope to linux only. Please be aware that this increases the complexity when building wine for multiple platforms by a lot.

well i'm not here for OSX nor android.. But i see no reasons why should we limit linux by incompetence of OSX and Android.. Linux has and is going to have supperior implementation of available features excluding those that are released exclusively on the platform and those are going to be assimilated on linux overtime too like WINE beeing supperior to native windows performance or DXVK supperior to DirectX in certain scenarios or even playing Console exclusives on 4K30FPS when we can play them on 8K120FPS, etc..

I'm using an Ubuntu based system and together with me a lot of other users too. I would also go so far and say that a large part of the PlayOnLinux users use Ubuntu compared to Gentoo and other Linux distributions.

Why do we limit gentoo considering that the implementation seems effordless and is maintainance-free from upstream.. And if needed we can provide a method for ubuntu users to compile their wine or ubuntu users can in theory greb .deb or some external repository for different WINE versions..

Yes but do you think it is a good idea to force users of Phoenicis to add an additional repository? Especially if they require their previous wine version for other applications. In addition it makes it difficult to use multiple different wine installations at the same time.

No i don't think it's good idea i would even go as far to say that it's insane to use system wine on distros like ubuntu.. I'm saying that such implementation may (or is) mandatory for rolling distros and is preffered.. None is asking you to provide system wine scripts for ubuntu..

Kreyren commented 5 years ago

recommends keeping the conversation short this is getting out of hand..

Kreyren commented 5 years ago

i'm appealing on providing system wine as an option in phoenicis.. I need this function for my LFS and Gentoo for reasons provided since i prefer to use master version of wine with changes.

plata commented 5 years ago

Mainly none of the scripts will work if you try to use system Wine because they download the required Wine version. Therefore, your particular use case is nothing we want to support in Phoenicis officially. If you want to do it anyways, just link the required files/executables in the Wine folder to your system Wine.

madoar commented 5 years ago

@plata didn't POL4 provide a Use system Wine function?

Kreyren commented 5 years ago

@plata didn't POL4 provide a Use system Wine function?

Lutris also does that

plata commented 5 years ago

@madoar I don't know. @qparis is this the case?

qparis commented 5 years ago

POL 4 provides wine system yep

plata commented 5 years ago

Ok, is this something we want to have for Phoenicis?

qparis commented 5 years ago

Maybe but this is not easy task either

plata commented 5 years ago

Honestly, in my opinion we should not do this. It will only lead to bug reports we are unable to resolve or issues which would not occur with our Wine (e.g. also related to https://github.com/PhoenicisOrg/phoenicis-winebuild/issues/62).

madoar commented 5 years ago

I think it depends how we support system wine. If we allow it to be used inside scripts then I agree it will lead to move problems. Alternatively we can also add it only to the Change engine dialog. This would ensure that all scripts are installed with an engine built by us, but the user has the freedom to change it later on to his host wine.

Kreyren commented 5 years ago

@plata

It will only lead to bug reports we are unable to resolve or issues which would not occur with our Wine

I would suggest ignoring bug reports with wine from those or in theory implement a method to perform sanity check? alike is vulkan present on the system etc..

I think it depends how we support system wine.

I suggest interpreting the function and not provide support for end-users -> make script maintainers responsible for scripts like that.

plata commented 5 years ago

@Kreyren it's not that easy. Your proposal assumes that our users are aware that an issue is caused by system Wine. This assumption is not valid in general.

Kreyren commented 5 years ago

@plata output huge error message for scripts that are using custom wine and point them to maintainer.. I have no problem with providing support for gentoo users with this..

Also gentoo's users know what the issue is caused by usually.. Same applies for LFS which i also plan to make scripts for :3

plata commented 5 years ago

Still... If you have users without development background, this will not really help. They will only see that there is a problem and therefore open an issue.

Kreyren commented 5 years ago

@plata Gentoo/LFS/(Arch?)/(Debian sid/buster/unstable?) are not noobs this adaptation is expected and welcomed. I'm not suggesting to use this for ubuntu, etc.. + we can make a sanity check for gentoo about what useflags are required for application A and output err if those are not met, etc.. etc..

plata commented 5 years ago

I'm not talking about Gentoo users. I'm talking about our average user. We cannot introduce what you suggest only for a certain group of users.

Kreyren commented 5 years ago

@plata Average user is irelevant for this approach.. Is meant to be used for distro specific scripts.

plata commented 5 years ago

We will not support distro specific scripts in the official repository. If you want to make your own repository, it's possible without any problem.

Kreyren commented 5 years ago

@plata We should, https://bugs.winehq.org/show_bug.cgi?id=46704 is a good example why distro specific scripts are a good thing -> League Of Legends is working on most distros (based on provided info), but is broken on debian.

I can't really provide support to all distros that are in unix for my scripts none can probably..

Also this feature can be included painlessly assuming that we need to add definitions for more script.json variables..

ImperatorS79 commented 5 years ago

This bug is certainly a distribution packaging bug, that will be certainly fixed by the distribution (or by wine if wine is relaying on undefined behaviour, but this is highly improbable (it happened though)). So nothing to do with phoenicis.

Kreyren commented 5 years ago

meh.. Still would rather have this variable

plata commented 5 years ago

Obviously, the above discussion lost focus. From what I can tell, the (maybe) still open topic is system Wine. If anybody is still interested in this, feel free to open a new issue in in https://github.com/PhoenicisOrg/phoenicis.

Kreyren commented 5 years ago

You said that you don't want to provide system wine which is still insane on high-end distros..

plata commented 5 years ago

Yes, I said so. However, that was my personal opinion which does not necessarily mean that it will not happen for Phoenicis.

ImperatorS79 commented 5 years ago

You could just provide a setting that let phoenicis use system wine when changing the container version, as done in POL4.

Kreyren commented 5 years ago

not necessarily mean that it will not happen for Phoenicis.

Then make it happend! Using current phoenicis wine on my system is just pure hell..

You could just provide a setting that let phoenicis use system wine..

YES YES YES YES YEEEES!!!