Add baseapp for building Wine on top of it #1830
Conversation
With added multib support for nested files
that could be inherited by based-on apps
Required by wine 5.7+
|
Build 33956 successful |
| sha256: 7d281276b480da3935d1acb239748c2c9db01a8043aad7e918ce57a223d8cd24 | ||
|
|
||
| - name: SPIRV-Headers | ||
| x-multilib: false |
There was a problem hiding this comment.
SPIRV-Headers installs files to lib/cmake/SPIRV-Headers. I think it's safer to enable multilib, so these files will also be installed to lib32.
There was a problem hiding this comment.
I believe Wine doesn't use cmake and looks up for headers directly.
| config-opts: | ||
| - --disable-static | ||
| - --disable-slapd | ||
| - --disable-slurpd |
|
Upstream know about flatpak'ing WINE attempt? Would be nice if they are also involved. There few different ways how WINE could be packaged and they have advantages and disadvantages. This requires wider discussion. |
|
This doesn't build wine but only wine dependencies. With this merged building full featured wine in flatpak would be a breeze. Without it everyone would have to reinvent it themselves. |
|
@Erick555 i am not asking about this WineBaseApp, i'am aksing in actual WINE Flathub thread and another one attempt to push WINE on Flathub. One of many. I've already built upon this BaseApp mine toy apps. And there still many things which need to discuss how to package WINE...
Building WINE would be a breeze, building WINE properly and building WINE derivatives (wine-stable/wine-staging/proton-standalone) properly would be not breeze. Flathub admins probably not for no reason against packaging WINE for a long time so i've just decided to ask is it worth to wait it or not? Because people asking and file a bugs/requesting features. Also it would be good to get at least blessing from upstream and not to hear something like: "If people want to do unofficial builds like < snip > against the freedesktop.org SDK instead of against soldier, you're welcome to do so, but < snip > are not going to support the result." |
|
This thread is about wine WineBaseApp. I don't know what the actual WINE Flathub thread is that you refer to but certainly you commented in this one an not in the other one 😄 . Wine is already packaged in flathub by few projects (proton, lutris) so I don't understand why you claim that flathub admins would be against it. I also don't understand why wine upstream blessing has any matter while we aren't talking about standalone wine flatpak app that upstream may be interested (or not) to maintain but bundling wine by projects which make use of it like lutris, playonlinux, q4wine, proton, etc. It's those projects who will decide how they build wine and wine upstream has nothing to say about this. |
Well, thats the main problem and thats why i said this required wider discussions and Wine packaging related discussions fragmented. Maybe i missed something. BTW WineBaseApp attempt was in 2018, then another one and now this.
Please read OP: Building a standalone Wine flatpak on top of it is also a possible use-case.
FH admins against Windows applications on Flathub (me too 😄) and also against WineBaseApp and this in turn mean step away from packaging standalone, reusable Wine package (or runtime/extension) on Flathub.
The main point not upstream here. And this is only your opinion and once again, that's why i ask for wider discussion, since other maintainers think differently and disagree with you. Having one, properly packaged, battle tested, reusable Wine build > awkward, custom Wine build packaged by this launchers like Legendary, Minigalaxy, q4wine, Lutris and such. But those who need to package custom build for their app always can do this for sure. |
|
I repeat again that this PR doesn't provide wine but only 3rd party dependencies that aren't affiliated with WineHQ so I don't know what kind of action you expect from them. Building standalone wine flatpak app which reuses baseapp is possible but not mandatory and the baseapp would be useful even when there would be never standalone flatpak app on flathub.
Nobody contested that.
Nope, this comment wasn't about wine baseapp , in fact this PR was done due to feedback in the other PR which had wider scope.
Then please open PR with
I don't see any disagreement with what I wrote in the quote. Whether apps bundle wine or use extension is irrelevant as the baseapp can be used in both cases (but don't have to). |
|
To sum up, wine baseapp can help with:
Saying that any of above three should be done instead of baseapp misses the point. |
You can repeat as many times as you want if this helps you pushing WineBaseApp and Wine Standalone on Flahub. ;) Maybe if you continue repeat another 3 years then other maintaners and FH admins in particular one fine day will not against WineBaseApp (1, 2, 3). Also maybe upstream Wine had a vision how should packaged his own software. And maybe they also prefer to not package this WineBaseApp. Who knows. All this mean Wine packaging in broad sense requires discussion first and involving all stakeholders including upstream. At least they MUST notified first. Maybe you do not understand what broad sense mean. To begin with that after talks in IRC we count three possible options how Wine could be packaged and no one still sure which one is better and have their strengths and weaknesses. Even barthalion said it requires more discussion.
Just one comment above you contested that. :) Also if nobody against Wine as standalone package why it's still not packaged and not available then even if it was asked in 2017 (or a base flatpak just like Electron)? We almost in 2021. :) And against WineBaseApp, i can repeat this one more time since you don't even read what i wrote (1, 2, 3). Also silence for such long time in this thread mean that FH admins still not convinced in WineBaseApp idea, maybe you just can't understand this, i don't now.
I don't know why you trying twisting things but this even more like saying black is white - 1, 2, 3.
Why you asking me to call upstream if submitter should do this in first place when submitting app (or something that will hardly depend on it, like this controversial BaseApp proposal)? But i'll do.
Probably i better give up there trying to explain to you that this goal also pursues packaging standalone Wine which mentioned in OP of this thread and which discussed in IRC. And standalone Wine = upstream attention in any case.
They can, but in ugly way. Note, that you still missed main point — requires more discussion which in turn including how Wine should be packaged for being reusable and being available as standalone app in same time. BTW Winepak in early days wanted to package Wine as runtime IIRC. To sum up: ping upstream first before wasting time with such BaseApp proposal which was denied by FH admins for 3 years. And ask upstream about:
|
|
My only goal here is to convince you to stop making comments that are unrelated to this PR. This isn't all things wine general chat so please move it to some more appropriate place like discourse.
Maybe they had so please go and ask them. This PR doesn't package their software so this is orthogonal.
I didn't. I don't know what you are referring to but this is some total misunderstanding.
I don't know if nobody is against stadalone wine package in flathub because it was never proposed. Wine based launchers were accepted here. I proposed you to submit
It's possible that you are writing about things you don't know as you may didn't read all discussions and submitted manifests. Earlier attempts to bring wine/winebaseapp to flathub had different, wider scope and this PR acknowledges that making the scope more narrow and more concrete to address feedback from reviewers. Flathub admins certainly aren't convinced yet about having this on flatub otherwise they would already merged it. It doesn't mean it's not worth trying to convince them. I think it's unfair to criticize people who did some work in order to try making wine story on flathub better by person who didn't do anything in that regard and yet complaining there in no wine on flathub in 2021.
Comments about different proposals doesn't apply here and comment about this version was answered
Because you may be the only person in the world to date who thinks this is sensible for this PR. There is no app here and it won't depend on any other app (the others apps may depend on it instead). I'll take your word on this.
Certainly you should give up on this here because this PR doesn't pursue packaging standalone wine app, it only makes it easier among other things I listed. I assure this is hopeless for you.
It may be sad that you make a list of things other people should ask upstream while nothing stops you from asking them yourself. Don't ask what other people can do for you, ask what you can do for them 😄 .
Do you understand what happens when there is no baseapp? They (and everyone else) would need to reinvent all those hundred lines of manifest themselves. This is not fedora or debian where you can get all dependencies you need from the repos - there is no repo here - everything you need at build or at runtime you have to put it manifest, build and maintain by yourself (unless it exists in runtime but it's minimal). If you have multiple wine versions or flavors then you have to repeat it for every one of them. This is what makes wine story on flathub hard and what discourages developers of wine related apps from using flatpak. This is why this PR exists. Without realizing this the whole discussion is pointless. |
Finally you understand this. Good. That was my (and not only my) one of main point - discuss first. But sadly you derailed thread right from beginning.
Finally you understand this. Good.
If you think flaming, flooding, constantly straw man'ing and opening new the same proposal with WineBaseApp over and over for three years will convince them and if you calling this making wine story better - good luck to you and good day, sir. Also which people i criticized if i was the first one who vote for this proposal and waiting it for a long time for Minigalaxy and few some other apps? I criticized only:
Also saying that i didn't anything in that regard without any proof is pretty ignorant on your part but seems like making such statements is pretty OK for you. We packaged this build (based on WineBaseApp) in our own repo for a decent period of time. I've meticulously tested it, reported issues, small fixes and such.
Yeah, but i still try in simplest way form for people who have problem with logic: packaging WineBaseApp proposal rejected many times by FH admins. If this stopping from packaging us reusable, Wine-standalone package which we all waiting for such long period of time - then we should close this and focus on Wine package itself already especially if Flathub admins not against packaging Wine itself. Some app devs mad that Wine still not packaged on Flathub, i will not link this threads there, this is not necessary. Also the author main goal of this proposal is packaging Wine, WineBaseApp is just consequence. Instead of waiting another 3 years we can package right now fully functional Wine package which built from sources.
I don't know you just a troll or something but this Flathub policy requirement. If it's still hard to understand for you that this BaseApp just a gateway to achieve main goal - package Wine on Flathub, then you can ask author of this proposal yourself. And my first question, which you de-railed, was exactly about whether any attempts and request to package upstream Wine devs? Since i can't find any and if there no i wanted to do that. Since any logical conversation not possible with you please just don't bother anymore. My original question even not addressable to you. |
|
If you think this PR is made for flaming and flooding then I don't think anyone should talk to you about wine on flathub anymore. Your frustration that it wasn't accepted by flathub can't justify blaming people who take their time to prepare it. If you don't like it then make something better but not insult others.
Discussing wine packaging with upstream is great idea just not in place where wine packaging doesn't actually happen. This baseapp will be useful even when there will be never standalone wine flatpak on flathub.
This doesn't justify hijacking this PR for such thing when it had concrete narrow scope.
If you think nobody cares about this PR then I don't see why you are wasting your precious time on it. Just move on.
It doesn't matter what you did in your private repo. You never made an attempt to make handling wine easier in flathub and are actively insulting people who did.
The point is it isn't. For example electron baseapp (which is by far the most popular one) has no affiliation with electron upstream and AFAIK was neither proposed them to maintain as it wouldn't make sense when it has 0 electron code inside just like this baseapp. for wine. Certainly logical conversation isn't possible when instead of trying to understand what is being replied, you just keep repeating everything you said before like in an echo chamber without realizing it wad debunked many times over. I really hope this was your last post in this thread. From my side this is EOT. |
Another your straw man example. Why anyone shouldn't talk with me just because of one troll which flooding in every WineBaseApp packaging thread for three years and posting useless nonsense that no one even replied?
About what people your talking about? If about PR author then i can repeat — his main goal packaging Wine on Flathub, not this PR at all. If you talking about yourself i can't say that flaming and trash posting in every BaseApp thread = making something better. Maybe only in your parallel universe. Also please quote who have i insulted here and where. If you can't — stop lying, this will not help you pushing WineBaseApp. :)
Yeah, except you missed main point that i asked question (which you de-railed) to OP who want to package Wine in first place. In short: closing this BaseApp proposal — pushing Wine package since admins not against it — PROFIT. And no need to wait another three years and reading the same @Erick555 trash posts about how important BaseApp is and do not add anything useful to discussion.
Two at once wrong statement. Jesus, you trashposting on Flathub in Wine threads for three years and still posting such BS.
We have different goals to achieve from beginning. You prefer to trashposting in Wine flathub threads for three years and talking about making Wine history better instead of ask upstream first to package Wine. I would, in turn want Wine package on Flathub just like everybody else. And since META Wine Flathub thread doesn't exist (even if admins said this requires in first place for those who want to package Wine) and there still no even upstream request i've asked perfectly logical questions which is mandatory for achieve ultimate goal — having Wine package on Flathub.
Nice try. :) At this point we can clearly state that you are liar or just ignorant and not even reading and follows proof-links but keeping attacking your interlocutor and making fallacy arguments. gasinveins repo not mine, it's gasinveins repo 😁. Jesus. And when he will push this Wine build (if he will) all history commits will be preserved and i don't see you up there. ;)
You have serious problems with self-reflection. No, it's not my last post in this thread just because one troll de-railed thread and my question. From my side this is block one more trashsposter. |
|
Seriously. I know I'm not a mod or anything, but please take it to DMs or mails. I subscribed to this MR because I want to see ACTUAL work put into this, not an argument. |
|
Wine Flathub [META] |
|
Queued test build for org.flathub.WineBaseApp. |
|
Started test build 38143 |
|
Build 38143 successful |
|
What is the state of this PR? Is there anything preventing it from being merged? |
Anyone? I'd like to see this merged for use in Minigalaxy |
|
Sorry, at this point it is clear that this isn't going anywhere. Besides, I concluded that a flatpak app containing Wine itself would be more useful than this one. For whoever interested, here are recipes for building a Wine flatpak app, which could be both used standalone and as a baseapp for other apps. |
|
Following up conversation on Matrix, please submit it with explanation what use case and possible branches are, and we will see where to go from there. |
|
Old upstream thread with use cases and branches suggestions: https://forum.winehq.org/viewtopic.php?p=130824&sid=b8579645b1f2636da3f7869f84afdf0f#p130824 |
|
Opened #2845, a flatpak with Wine itself. |
This app contains dependencies used by Wine (as of 5.10+). It's intended to be reused as a baseapp for building apps that make use of Wine, like Lutris, Minigalaxy and such. Different apps may want different Wine flavors, but they have more or less common set of dependencies - thus, a common baseapp. Building a standalone Wine flatpak on top of it is also a possible use-case.
generated/*.jsonmodules are procedural-generated frommodules/*.yml.