Clear Linux Moving Ahead With Their Third-Party Packaging Support

[phoronix]

Phoronix: Clear Linux Moving Ahead With Their Third-Party Packaging Support

In recent months we've heard of Intel engineers working on better supporting third-party packages on Clear Linux that would be akin to Arch's AUR, Ubuntu's PPA, or Fedora's Copr systems for allowing unofficial/third-party packages to be more easily made available particularly in cases of closed-source software. It looks like that internally that system is now in beta as they work towards having more software available on Clear Linux...

http://www.phoronix.com/scan.php?page=news_item&px=Clear-Linux-Third-Party-Beta

[tildearrow]

I don't know why but when you mentioned "Third-Party Packaging" in the title I thought you meant something like building Debian packages, RPMs or Arch Linux packages from Clear Linux.

[enihcam]

Merge Archlinux and Clearlinux, done.

[audir8]

This was definitely a big missing feature for Clear Linux. If chrome, nvidia, opera, others who don't have updated flatpacks... end up with easy to install and regularly updating Clear third party packages, I can definitely see my self picking it up and recommending it to others. There is quite a bit to like about this rolling release stateless distro.

If it's all integrated with mixer and swupd which I'm guessing it is, all the better.

[boxie]

... and this project is getting more and more interesting

[polarathene]

It'd be nice if there was a tool that would let you use third-party/community repo support from other distros on your own choice of distro. Some sort of abstraction/compatibility layer to convert from one format to another, and establish appropriate dependencies, remap file paths/locations if needed, etc. Referencing equivalent packages(and perhaps their histories) from different distros, perhaps some cross-referencing/patterns could be established?

I dunno the difficulty of creating/maintaining such a tool would be from a normal dev approach, but with enough input data and some training/guidance, could be a good use of machine learning?

I know there's something similar that takes the opposite approach, PackageKit I think it's called? But that's more aimed at making a package once that can be distributed to multiple repos with the different requirements they have. Doesn't mean that anything on AUR could be used in another distro like openSUSE. The AUR is a big lock-in for me, other distros don't seem to be on par(that includes openSUSE last I checked for packages I used).

That said, it would be nicer if more package maintainers(for third-party/community) did so in a non distro specific manner so everyone can benefit. I'm guessing PackageKit lacks certain features/support or adds other friction vs maintaining a package for a specific distro?

[ms178]

It'd be nice if there was a tool that would let you use third-party/community repo support from other distros on your own choice of distro. Some sort of abstraction/compatibility layer to convert from one format to another, and establish appropriate dependencies, remap file paths/locations if needed, etc. Referencing equivalent packages(and perhaps their histories) from different distros, perhaps some cross-referencing/patterns could be established?

I dunno the difficulty of creating/maintaining such a tool would be from a normal dev approach, but with enough input data and some training/guidance, could be a good use of machine learning?

I know there's something similar that takes the opposite approach, PackageKit I think it's called? But that's more aimed at making a package once that can be distributed to multiple repos with the different requirements they have. Doesn't mean that anything on AUR could be used in another distro like openSUSE. The AUR is a big lock-in for me, other distros don't seem to be on par(that includes openSUSE last I checked for packages I used).

That said, it would be nicer if more package maintainers(for third-party/community) did so in a non distro specific manner so everyone can benefit. I'm guessing PackageKit lacks certain features/support or adds other friction vs maintaining a package for a specific distro?

Why stop there? I could imagine a big central open source repo with all the source code of every open source project out there from which each distribution bases its packages from with their custom build flags/packaging tools. No more missing software in your favorite distro which is available elsewhere and potentially getting newer versions sooner. Problematic is the packaging and distribution of the closed source stuff.

[phoenk]

It'd be nice if there was a tool that would let you use third-party/community repo support from other distros on your own choice of distro. Some sort of abstraction/compatibility layer to convert from one format to another, and establish appropriate dependencies, remap file paths/locations if needed, etc. Referencing equivalent packages(and perhaps their histories) from different distros, perhaps some cross-referencing/patterns could be established?

I dunno the difficulty of creating/maintaining such a tool would be from a normal dev approach, but with enough input data and some training/guidance, could be a good use of machine learning?

I know there's something similar that takes the opposite approach, PackageKit I think it's called? But that's more aimed at making a package once that can be distributed to multiple repos with the different requirements they have. Doesn't mean that anything on AUR could be used in another distro like openSUSE. The AUR is a big lock-in for me, other distros don't seem to be on par(that includes openSUSE last I checked for packages I used).

That said, it would be nicer if more package maintainers(for third-party/community) did so in a non distro specific manner so everyone can benefit. I'm guessing PackageKit lacks certain features/support or adds other friction vs maintaining a package for a specific distro?

This is literally the problem flatpak (and to a lesser extent, other formats) solves. Instead of having a N-to-N transformation that would be basically impossible due to all sorts of dependency problems, it allows applications to be packaged up into distro-agnostic packages that mostly (but optionally) share a common set of bases. It retains the ability for distros to maintain their own repos with their own policies and standards, while allowing large central repositories like flathub to exist that will have any package conceivable. You could even add another disto's repo to your system, ie add the Fedora repo to complement flathub on Clear Linux.

[phoenk]

Why stop there? I could imagine a big central open source repo with all the source code of every open source project out there from which each distribution bases its packages from with their custom build flags/packaging tools. No more missing software in your favorite distro which is available elsewhere and potentially getting newer versions sooner. Problematic is the packaging and distribution of the closed source stuff.

This goes on the assumption that all distros are simply a set of build flags and a favorite packaging tool. This is simply not the case. There are reasons why some software is included or not included in certain distros, which packages get updates, what kinds of updates, etc. Additionally, you could never have a single mega-repo on the basis that that one organization would control all the downstream efforts. Alternatives would naturally spring up to circumvent the mega-repo's policies, pushing us all back to square one.

[ms178]

This goes on the assumption that all distros are simply a set of build flags and a favorite packaging tool. This is simply not the case. There are reasons why some software is included or not included in certain distros, which packages get updates, what kinds of updates, etc. Additionally, you could never have a single mega-repo on the basis that that one organization would control all the downstream efforts. Alternatives would naturally spring up to circumvent the mega-repo's policies, pushing us all back to square one.

I have to admit that this was just coming out of my head but thinking a bit more about it, there might be ways to make it practical. You mentioned the mega-repo's policies and sure, it comes down how to govern this thing effectively with the aim to be the defacto standard. As there will be always alternatives, I could imagine it could start as a collaborative effort of several major distributions to deduplicate their packaging and distribution efforts. The distros could still chose which projects they might ship with in the end but keep the door open for users to get these other packages easy enough themselves.