Global Aur equivalent - GNU/Linux
eduarch42
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?
Dworin
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?
eduarch42
(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?
jkl
pkgsrc already exists. Welcome to nixers.
asyncial
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.
venam
(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?
Steph
(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.
eduarch42
(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.
z3bra
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?
eduarch42
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?




Members  |  Stats  |  Night Mode  |  Help