On Fri, Aug 25, 2023 at 10:42 AM Michal Suchánek <msuchanek@suse.de> wrote:
On Fri, Aug 25, 2023 at 09:29:12AM +0200, Roger Oberholtzer wrote:
> Not intended to start a violent discussion with this as I am not decided on
> it, but I am guessing that it is hoped that flatpacks as an alternative
> might clear this up. At least for complete applications. In another thread
> I was wondering about how all that worked in a development environment
> where you need all the bits that will eventually go into your flatpack.

Then instead of wasting resources on OBS you can waste resources on
flathub and your machine. Your choice. Flatpaks tend to be _very_
wasteful when it comes to space, tend to integrate poorly with the OS,
and security updates tend to be problematic because there would be many
copies of each library. YMMV.

I'm not a flatpack user. And as a developer I am curious how one gets all the various libs/components needed for an application in the flatpack world. They would, I would imagine, still need to be made the current way, and then packaged into flatpacks along with whatever bits are needed.

So in a flatpack developer's world, all the work/hassle to get the needed components must still exist. Or do people think that the flatpack developer also builds and maintains all the 3rd party libs needed to make that flatpack? I can't think that's the way.

But I think it would be great if there was some more organized way that the binary compatible things built in OBS were managed. Like a '15' target for all the things that can be used in 15 and all the point releases. If that would be difficult to manage (tracking compatibility), then my original point of things all being built for the current point releases would be good. To only have, say, 15.2 seems incomplete.

--
Roger Oberholtzer