4 ms·

Yeah, I might be wrong when saying that services are automatically enabled in Arch. My understanding is that Void has xbps-src [1], [2] for installing packages

Yeah, I might be wrong when saying that services are automatically enabled in Arch. My understanding is that Void has xbps-src [1], [2] for installing packages from source code, and it is somewhat similar to AUR. Xbps-src package database is essencially a github repository, you clone it and use it to build and install packages for your system. I installed it and used only once to build some obscure video streaming program, which failed to compile, and I did not follow up to figure out why it failed. [1] https://github.com/voidlinux/void-packages/blob/master/README.md https://github.com/voidlinux/void-packages/blob/master/READM... [2] https://wiki.voidlinux.eu/Xbps-src https://wiki.voidlinux.eu/Xbps-src

daptaq 9y ago
The difference would probably be that while anyone can add (or update) a package to the AUR, the xbps-src maintainers have to explicitly allow this. On the one hand it makes it harder to start contributing, but on the other hand, there is a minimum level of quality that is maintained. After a while you get used to it though, and ultimately updates are processed pretty quickly, especially if the submitters know what they're doing.
- hex12648430 9y ago
  >The difference would probably be that while anyone can add (or update) a package to the AUR, the xbps-src maintainers have to explicitly allow this. Nothing is preventing other users to fork or start their own void-packages repo on any git hosting service of their choice. In that sense it's actually more open to contributors than the AUR. Now the experience for the end user might not be perfect if they don't know that such a repo exists.
  - daptaq 9y ago
    But you can do the same with the standard arch repositories too. The (intended) advantage of the AUR was precisely that people don't have to create their own repositories that are hard to trust and have to be updated all the time, can fall out of maintenance, and only the original creator can access (quasi like Ubuntu PPA's - which I personally hate). That's not to say that the AUR has no downsides, but what you're describing wouldn't make it better, imo.

daptaq 9y ago

The difference would probably be that while anyone can add (or update) a package to the AUR, the xbps-src maintainers have to explicitly allow this. On the one hand it makes it harder to start contributing, but on the other hand, there is a minimum level of quality that is maintained. After a while you get used to it though, and ultimately updates are processed pretty quickly, especially if the submitters know what they're doing.

hex12648430 9y ago
>The difference would probably be that while anyone can add (or update) a package to the AUR, the xbps-src maintainers have to explicitly allow this. Nothing is preventing other users to fork or start their own void-packages repo on any git hosting service of their choice. In that sense it's actually more open to contributors than the AUR. Now the experience for the end user might not be perfect if they don't know that such a repo exists.
- daptaq 9y ago
  But you can do the same with the standard arch repositories too. The (intended) advantage of the AUR was precisely that people don't have to create their own repositories that are hard to trust and have to be updated all the time, can fall out of maintenance, and only the original creator can access (quasi like Ubuntu PPA's - which I personally hate). That's not to say that the AUR has no downsides, but what you're describing wouldn't make it better, imo.