Hi, this is my first post,

Imagine an all distro compatible AUR equivalent, will it be easy to maintain or will it be even possible?

What do you guys think?

Welcome to nixers.

Regarding your idea, how would you imagine the makepkg equivalent to check for {,build} dependencies? And how to tell the package manager that you're installing files without knowing which package manager is used?

(05-12-2018, 12:08 AM)Dworin Wrote: Regarding your idea, how would you imagine the makepkg equivalent to check for {,build} dependencies?

It could try to detect current package manager and check dependencies.

(05-12-2018, 12:08 AM)Dworin Wrote: how to tell the package manager that you're installing files without knowing which package manager is used?

Check the ways package managers know if a package is installed and modify it.

I really don't know if the solutions provided are the ideal, or if a cross-distro AUR equivalent is not possible, but i got excited when i came up with it. How can we make it work in all distros? Is it even possible?

pkgsrc already exists. Welcome to nixers.

I actually thought about this, too, back when snap and flatpak gained momentum. I think it is an interesting idea, but very difficult to achieve, because of the plethora of different package managers. I would agree with jkl, that it would be easiest to use another package manager, perhaps installing to a local path in $HOME. This could be pkgsrc, as well as nix and possibly others.

(04-12-2018, 08:58 PM)eduarch42 Wrote: Imagine an all distro compatible AUR equivalent, will it be easy to maintain or will it be even possible?

This comes back to the question of it's good to have centralized package management or not and if there needs to be an authority for this package management or if it's anybody in the community that could possibly contribute. Are those rolling releases or not.

For me this is the same thing as what is currently happening with package managers that are specifically designed to install packages of a programming language, python, ruby, rust, nodejs, etc.. all have this.

I'm not sure if this is better than the centralized package management. What do you think?

(05-12-2018, 11:01 AM)venam Wrote: This comes back to the question of it's good to have centralized package management or not and if there needs to be an authority for this package management or if it's anybody in the community that could possibly contribute. Are those rolling releases or not.

That's a really tough question.
I will say that it is really annoying to deal with multiple package managers.
On my mac I regularly deal with pip, brew, and emacs packages. While this isn's that many, I still would rather only have to use one package manager.

In a discussion a couple weeks ago the idea of "reinventing the wheel" was brought up. Isn't having multiple package managers a perfect example of this?

I realize that the diversity of software is a great strength in our community, being able to pick dwm, or i3, or ratposion or whatever is great, but when everyone has to use a handful of package managers, isn's there a problem. Idk.

(05-12-2018, 11:01 AM)venam Wrote:

(04-12-2018, 08:58 PM)eduarch42 Wrote: Imagine an all distro compatible AUR equivalent, will it be easy to maintain or will it be even possible?

This comes back to the question of it's good to have centralized package management or not and if there needs to be an authority for this package management or if it's anybody in the community that could possibly contribute.

Firstly, wow, venam replied to my comment (I really admire you for 2bwm).
I have had also trouble with pacman and pip, and i imagine more trouble would happen if i knew more programming languages because it would mean more package managers for each one. So i do think centralization should be the way to solve this issue. But im also concerned that having one central power controlling all the packages is not the best way to go. There needs to be a way of decentralizing (kind of community powered) the package managers, but at the same time only having one global package manager to avoid conflicts between others.

(05-12-2018, 11:01 AM)venam Wrote:

(04-12-2018, 08:58 PM)eduarch42 Wrote: Imagine an all distro compatible AUR equivalent, will it be easy to maintain or will it be even possible?

Are those rolling releases or not.

What i think is that it should be rolling, as it is a global package manager, it wuld be exhaustive to test every package with all distros.

(05-12-2018, 11:17 AM)Steph Wrote:

(05-12-2018, 11:01 AM)venam Wrote: This comes back to the question of it's good to have centralized package management or not and if there needs to be an authority for this package management or if it's anybody in the community that could possibly contribute. Are those rolling releases or not.

I will say that it is really annoying to deal with multiple package managers.

I totally agree.

Package management is a hard problem to solve. You get to answer difficult questions...

• How do I handle dependencies?
  
• How do I ensure compatibility between software?
  
• How should I rollback versions?
  
• How do I keep track of updates?
  

...And even more!

If we use non-distro specific terms, your idea would be a kind of hub where people can submit recipes to build and install any kind of software.
This is a marvelous idea, that [/url=https://crux.nu/portdb/]predates Archlinux[/url]! Amd I said that, not only because I love communism, but because it has many advantages, like early release, huge choice of packages, big efforts shared accross users, you name it.
Unfortunately, just like communism, it also has flaws, that are to be taken in consideration:

• orphanage: people create ports once, and give up on the realeases
  
• duplicates: this is the response to the above issue
  
• mediocrity: not anyone can write clean recipes
  
• chaos: organisation is impossible in this mode
  

I realized that while I was the happy maintainer for a hundred crux ports. Even though I put some effort in keeping my ports up to date, usualy people made their own port when mine where outdated rather than notifying me. Some even recreated them, just so they could put their name in the comments instead of mine!
I also realised that after cloning ports trees from multiple users, I had multiple ports named differently for the same packages, but at different versions, and I had troubles knowing which one was the most up to date.

The main problem for this approach IMO is that contributors must be honest, which is not going to happen soon.
Another barrier, is cross-distro compatibility. You will never be able to provide a build recipe that will work on ARM, x86, Glibc and musl at the same time (I don't think even pkgsrc can't achieve that!).
As for integration with multiple package managers... It's a lost cause already unfortunately. Your best bet would be to use them all at a time.

I still believe this is a good idea, bjt that would only work with a small community, to keep things under control. What do you think?

What about creating a repository for each "popular" package managers (apt, xbps, rpm, etc). And port the AUR packages to each repository, and kind of "chain" them in order to maintain all of them updated.
Example: I submit my own window manager to AUR, then a script detects there is a new package in the AUR, and creates a new package for another package manager.
I think that with this solution it will be easier to maintain and more reachable. Because it doesn't involves the creation of another package manager. Only the creation of "mirror" repositories of the AUR.
What do you guys think?

(06-12-2018, 09:12 PM)eduarch42 Wrote: and kind of "chain" them in order to maintain all of them updated.

This sounds nice and all, but it flies in the face of the way packages work. The linuxverse is crazy in that so many distros ship with so many different versions of packages and different packages that depend on other packages.
Did I say packages enough times? its a mess.

The Linuxers had one standard package management system defined. They could have had it so easy...

Dumb kids.

(06-12-2018, 09:12 PM)eduarch42 Wrote: Example: I submit my own window manager to AUR, then a script detects there is a new package in the AUR, and creates a new package for another package manager.
I think that with this solution it will be easier to maintain and more reachable. Because it doesn't involves the creation of another package manager. Only the creation of "mirror" repositories of the AUR.
What do you guys think?

You can probably make some helper scripts but to have unsupervised uploading of untested 'translated' packages to repos doesn't seem like a good idea. You'd still need to build and test on each target distro.

How about a kind of clean chroot system that lets you choose which distro is used for building a package?

(06-12-2018, 11:56 PM)Dworin Wrote: How about a kind of clean chroot system that lets you choose which distro is used for building a package?

I had such an idea in mind for an automated packages build.
Start with an empty directory, and install only the dependencies. This way you can ensure that you got all the dependencies right, and that your software is gonna work correctly.

Now to add on top of the cross-distro idea, the best solution would be, IMO, to go with static linkage.
This would make your binaries work on any host with the same architecture, no matter the libc, of libraries installed.
This is also faster to run, and definitely not bigger than say, snap or flatpack "apps", which ship all the full runtime dependencies along with each software.

For the repository, I prefer going with how crux handles it, rather than arch: maintainers host the repositories themselves, instead of pushing to a central repo.
This has the advantage to give more responsibility to maintainers, and prevent orphanage. Web hosting is now cheap, and you could even use online "hubs" to host your port tree like http://repo.or.cz.

So is this idea dead already?

(12-12-2018, 06:38 AM)z3bra Wrote: So is this idea dead already?

I feel like you summed it up well when you described the difficulties of creating such a system.

If such a thing was feasible I would bet it would have already been implemented.

(12-12-2018, 11:35 AM)Steph Wrote:

(12-12-2018, 06:38 AM)z3bra Wrote: So is this idea dead already?

I feel like you summed it up well when you described the difficulties of creating such a system.
If such a thing was feasible I would bet it would have already been implemented.

Such a thing already exist, I just didn't want to spoil the idea with pre-made options, to see what we would come up with.
If the idea dies with the first difficulty though, we won't go far indeed :)

Distributed user repositories:

• https://crux.nu/portdb
  
• ???? - some linux ports that can be built on any distro, POSIX shell only (can't remember the name!)
  

Package manager wrappers / Cross-platform

• https://www.freedesktop.org/software/PackageKit/
  
• https://github.com/silvernode/tux
  
• https://www.howtoforge.com/pkgwatch-a-pa...nt-wrapper
  
• https://github.com/jordansissel/fpm (different approach)
  
• https://github.com/icy/pacapt
  
• https://www.pkgsrc.org/
  
• http://0install.net/
  

(12-12-2018, 06:38 AM)z3bra Wrote: So is this idea dead already?

Its been a long time, and i took it to think about how it could be implemented.

What about a package manager with no repositories and packages, giving it a type of scheme as the one of Uber (The largest taxi company without owning any car). It will not have packages because all of them will be hosted on their respective github/gitlab repositories.

Lets say i want to download a packages, ill just need to run "palo install venam/2bwm". Then the package manager will search for the repository in github/gitlab and clone it. After that it will search for any Makefile file in the repository and run it.

I know the idea its no so concrete, but atleast it will avoid the necessity of adding packages to a repository and make compete with other package managers that don't have a certain amountof packages.

What do you guys think?

Notes:
-(palo is just a name that i came up for the package manager, new ideas a accepted)
-(Instead of using a Makefile, we could create a global makepkg or makefile exclusively for the package manager)

I just stumble on the following: http://www.rastersoft.com/programas/multipackager.html . Can be added to Z3bra's list, I guess. Works by automating creation of VM with environment for a number of distro's. Haven't actually tried it or checked it out.

@eduarch42: Even though I like this idea, it has 2 main flaws:

First, not all softwares rely on git as their VCS, and not all of the git based projects are hosted on github/gitlab. If you want to build a drop-in solution, it should adapt to every solution out there.
A solution to that would be to use some kind of "driver" system, based on the protocol used to fetch a project: http://, ftp://, git://, gopher://, ...
It would hqve some corner cases, but could be more generic!

Second problem (which is huge IMO), is that there is no standard build system. And even out of all the build systems, all of them don't compile the same way.
From my experience, you cannot assume all makefiles have an "install" target for example. It means that you'll have to patch the makefile at some point, and for that, you need a way to keep track of your patches, and some kind of recipe to apply them.
The idea you propose (makepkg or global makefile) is how all package managers work already. They have an internal build recipe to create packages that the package manager can install/track.

Some other implementations try to "replace" completely any makefile, by providing a generic dropin build system: http://git.2f30.org/mkbuild/log.html
I love the idea but this looks too complex for me...

I went with a different approach myself, and decided to put the compilation process out of the package manager. You compile the software manually, install it in a chroot, and generate a tarball out of this chroot. this is your package, and the package manager can install it!
It leaves the user the possibility to use/create any automated build system he wants, and make use of an easy to understand and portable package format: a tarball.

Isn't GNU Guix or Nix kind of something along these lines?

(01-01-2019, 03:25 PM)zge Wrote: Isn't GNU Guix or Nix kind of something along these lines?

No idea for Guix. Nix has a package building recipe format like other package managers. Its difference resides in the fact it installs all versions of a package in a specific namespace, allowing multiple versions to coexist.

There is a nix project for using user repositories now - it allows wrangling package sources like: https://github.com/nix-community/NUR/blo...repos.json (these are not officially supported/is more AUR-like)

(01-01-2019, 08:20 PM)z3bra Wrote: No idea for Guix. Nix has a package building recipe format like other package managers.

Guix is basically a Scheme version of that AFAICS.

(02-01-2019, 04:34 AM)jkl Wrote:

(01-01-2019, 08:20 PM)z3bra Wrote: No idea for Guix. Nix has a package building recipe format like other package managers.

Guix is basically a Scheme version of that AFAICS.

And everything is free software. I haven't played around with nix too much, but I know that adding and using packages on Guix is supposed to be quite easy, see https://www.gnu.org/software/guix/blog/2...eagl-2018/ + GuidSD /= Guix (the package manger), so you could install Guix-packages on any distro.

In theory, yes, it was also reported to work on the Hurd, but I'm not sure how up-to-date that report is. I think their "GuixSD on the Hurd kernel" project is in a similar state.

I tried to make Guix (the package manager) work on Gentoo and I mostly failed though. Nix (the package manager) runs less badly.