Hello, I was originally not going to comment here, but nobody seems to have addressed a point I wanted to make. I will respond to the emails in the thread in a single email, so I apologise if this is long. Evan:
1. Difficult to feedback and difficult to contribute (to already existed package). If have any ideas or report, user need to send email to maintainer via email personally. This is not convenient for both maintainers and users.
Not really, comment/email a patch/diff to the author, then users are free to apply the patch to the package if the author does not apply it. In fact I would say this is more powerful.
2. Lack of Peer review, audience supervise. Some packages even if updated frequently by its maintainer, but it doesn't following good practice and not built from source (Not Java, native program), It retrieve from Debian or Ubuntu or Fedora packages, and extract or repackage it in Arch Linux package. And some packages may failed to build, or some of its dependencies are forgotten added by maintainer.
There is a lot of cases where peer review has taken place, a lot of people used to email aur-general with a new package and ask for possible improvements which could be made. There is a lot of bad packages yes. But Arch Linux believes in being pragmatic, if a package is too hard to build from source it is not pragmatic to do so. As with anything, it is better to get a working package, even if it is messy and awful, and then work on improving it gradually with others contributing as well, than be rigid on standards and have no working package. Repackaging is a big issue, and is generally against the Arch Linux way of doing things. You should match upstream as close as possible, so feel free to suggest for packages to adopt the upstream source code, and not the redistributed source code from other distributions (which have been patched and processed for their use cases), and if it is open source, binary builds should always be -bin and should be avoided, I know it is annoying building from source, but you can't patch a binary to work with the arch linux toolchain if it is not working properly. Source is the best way to ensure compatibility, and also the first step in preventing malicious binaries do not get redistributed to the Arch Community. Although, as for the peer review part, maybe it should be more encouraged to ask the mailing list for their opinions on specific packages, and to encourage more discussions. We have #archlinux-aur and aur-general, but they don't seem to be as popular as it used to be. The issue doesn't seem to be the AUR not being fit for purpose, but more the community is the issue (I am not trying to cause any offence, hear me out). The issue you are describing seems more like a breakdown in communication within the community, after all, no matter what changes you suggest, if the community doesn't discuss with each other and come to mutual agreement, then Arch Linux will never get anywhere. Community projects only work when the community actively discuss and seek solutions, but instead it seems like everyone is doing their own thing. Breakdown in communication is, in my opinion, the issue here. I would like to bring up another thing, it is vitally important that the communication between upstream and packager IS NOT broken. The best packages are those in which upstream gets a say in, and they are entitled to the package if they want it, but that doesn't stop you from contributing or giving ideas on improving it. Something I did a lot, maybe too much, was I would always contact upstream and get into conversations with them, obviously some of them are pretty antisocial and would simply ignore you, but the ones who did proactively discuss with you allowed you to package the software to a lot better quality, than if upstream bailed on you. After all, upstream knows their project the best, and you are likely to know the Arch packaging better than them, combine your efforts and you can achieve great stuff :) Unfortunately, apart from the Arch Staff which I believe do the above, it doesn't seem common in the AUR, which might also hinder package quality. But again, this is my opinion and something which worked for me (before you go looking, I do not currently hold any packages, I have orphaned them all due to personal reasons impairing my ability to keep them up to date).
3. The entry with a specific name in AUR is always occupied by the Maintainer who firstly register the package. If there is another maintainer who has better practice than the previous one, This maintainer has to rename his/her package as `xxx-bin` or some sophisticated name else. This is unfair. It lack of refreshing mechanism.
This is very fair. If the maintainer is being dismissive and ignoring you, then you can ask for Arch Staff intervention and they will solve the situation. Instead of fighting over who's name is under the maintainer field, why not give a diff or patch in the comments of how you would do it, and let people pick? Or the maintainer patch the package with it. I think people forget that git-format-patch(1) and git-diff(1) exist, and feel the constant need to have full write access, when in reality, you don't.
4. upstream software author is difficult to directly contribute to the AUR packaging contribution. For a great number of upstream software author, they are willing to participate in downstream redistribution process. Especially for those young software. But the current AUR workflow block their way to contribute on downstream stuff.
Upstream is free to ask to co-maintain, but you should be discussing with upstream either, if you and upstream are not getting along, you are doing it wrong. But again, git-format-patch(1) and git-diff(1) exist.
5. Currently,to evaluate whether a AUR package is eligible to move in Arch Linux official packages (extra repo), It only depend on votes and popularity and whether there is a maintainer willing to pick it up. However, those factors is too lack of details. To evaluate the robustness of the eco-position of a package, It should evaulate the discussion, issue report, contribution, and ... And it should be evaluated case by case.
This is not an easy thing to address, boolean logic doesn't work here, do you want an AI to run over a PKGBUILD and try to guess how good it is? Human beings, which surround you in the community, is an amazing way to check, email the mailing list, ask what you can do to improve the package. I am happy to read PKGBUILDs, although I am not as experienced as a lot of people here, so I am sure there is tons of others which can give you amazing advice, you have the power at your fingertips, reach out and grab it :) As for it being moved into the official repositories, votes make little difference other than making it be seen more. Package maintainers adopt what they use, and want to maintain, and drop anything they don't want into the AUR. As an Arch User, you are expected to be familiar with building packages, so whether it is in official or in the AUR shouldn't be an issue for you. Feel free to run your own unofficial repository [1], but do be careful with the security implications of using unofficial repositories.
1. Create a git repo on gitlab.archlinux.org named aur-meta (Or whatever names which maker users understand easily). This git repo keep a list (table of content) which point to the git repo URI of the AUR packages.
Pointless, and just causes more issues. People who are experienced would need to change their workflow, and the issues/PR feature will cause too much hassle to maintain.
2. For the AUR package, it can be placed on anywhere (github.com, gitlab.com, gitlab.archlinux.org, gitlab.gnome.org ...), the only things needed are these URIs are public accessible (can be git cloned by anyone who know this URI). And it need to keep its PKGBUILD on the top level of git repo.
Lets not outsource PKGBUILDs to other services, this is a bad idea, I can list a few which instantly came to head for you: 1. Privacy issues, data is stored across multiple providers, especially github and their constant abuse of their power will deter many from using the AUR if you start outsourcing. 2. Confusing and complicated, people will need to hold accounts with multiple different providers. I used my own gitea instance for a while but I found people just kept spamming you with version bumps, I can version bump in 2 seconds, but testing and checking for changes in dependencies, license etc takes more time. It promotes laziness and lack of care for packages. And even worse, opens up the door to CI/CD autobumping without a care in the world for whether the package actually works, something I have been very vocal about in the past, and something I still see often (rocketchat-server is one which comes to mind). 3. No way to easily tell what AUR packages exist or not, and the AUR will turn more into an index for hundreds of different remotes... it would just be a mess. 4. github, or gitlab or any other provider goes down, and then this takes out AUR packages, multiple points of failure, at least Arch Linux controls the AUR and thus is responsible for keeping it running.
3. The issue and affairs related to which upstream software is included and which PKGBUILD git repo is selected, goes to issues section of aur-meta. For packaging specific problems, it goes to the AUR package git repo.
Overcomplicated, and involves even more places to check for issues. Comment section is good enough for this. It becomes too many points of failure and too much mental overhead, juggling issues, comments, emails... its too much... and is why if I do choose to maintain packages again, I would 100% exclusively keep it to the AUR and not push it elsewhere, so many people recommend that workflow but it simply doesn't work.
4. If a package is orphaned or too broken/bad practice, the contributor who has access to aur-meta can simply change the pointer to a alternative PKGBUILD git repo which is better in practice and liveliness.
This then causes arguments, "my package is better than yours", then competition of who has more people pulling their package, and before you know it you got a flame war between the same package, but two different implementations. Also its overcomplicated. You must be able to discuss why one is better than the other, and pick the better of the two, even if that means yours isn't the one which is chosen.
5. If user find there is package which need to be improved, it can firstly report it to PKGBUILD maintainer via the issue section of git repo. If the maintainer long time not response or insist to keep bad practice. The user can write a proposal in aur-meta to change the pointer to another alternative. This is what a community driven packaging method should be.
Use AUR comment section, if there is an issue, ask for intervention from staff, or if they do not respond, submit an orphan request. Systems for this are already in place, don't see the problem you are trying to solve.
6. The name of entry in aur-meta is the package name, not the name of PKGBUILD git repo. (git repo can have different name). Many upstream software author would create a separate git repo along with their software repo which is dedicated for PKGBUILD.
Overcomplicated, and I do not see how this would help... Foxboron:
This would give similar capabilities to what portage from Gentoo does with it's source packages.
Funny enough, I have heard this is an issue. People fight over which ebuild is better, because I believe you can overlap the ebuild repositories in priority (similar to how repositories are done by priority in pacman.conf), wouldn't this just promote more fighting? Maybe you might like fighting for your PKGBUILD, but I much rather work together, and that is coming from someone who is antisocial :)
In theory there could also be a new group on gitlab.archlinux.org dedicated to AUR packages. Permissions to push towards these packages could be given out fairly relaxed and would allow you to piggyback on the existing infrastructure we have developed on gitlab.archlinux.org.
At this point, you may as well merge the AUR into the official repositories and do it alpine style, where you have one huge repository for all the PKGBUILD (or in their case, APKBUILDs) and everyone is allowed to submit PR, and the staff decide what is good/bad. You will turn your job, as a package maintainer, from maintainer to enforcer, where you enforce the rules instead of proactively maintaining packages. At this point you may as well just rewrite the entire of Arch Linux structure. I have always loved the separation between contributors and staff, the fact that AUR was a staging ground, and although Arch Linux is rolling release, it has been insanely stable. The amount of time and thought which goes into every version, along with the Arch Testing Team. The whole concept of "working your way up" would be destroyed, or would be dulled. The whole reason to contribute to Arch Linux is a bunch of fun is it not? Arch Linux hasn't got the stability of Debian, it doesn't have the same package count as NixOS, it doesn't have the financial and commercial backing like RHEL and its community forks, what it does have is a community which loves Linux, why ruin the fun? Of course this is my opinion, and I am sure there is a lot of people who get frustrated that they can't leverage the full power of the Arch Linux infrastructure because they are not staff, but this is exactly what gives you the drive to work towards! Jelle:
There is indeed a lack of Pull Requests, which would make it vastly easier to contribute. It would be interesting if someone can figure out how easy it is to implement that into the AUR.
And vastly more annoying, people will just submit "bumped to version x" without testing, without checking dependencies... it would just breed laziness. The time it takes to prepare a patch or diff is enough to ensure that you only submit it if there is there is an actual change, other than a version change. I have used PRs when I maintained my packages, this is not baseless, and I can assure you, the mental drain is awful! Plus, these are small build scripts (in most cases), PRs are useful for big codebases, for small scripts its no more than a hindrance.
That honestly, will always happen. There are simply too many packages in the AUR to make them all follw them. But this is more of point 1, no easy way to provide patches except of comments.
Or email, which is more than good enough. And patches can be applied by the user, if the maintainer refuses to apply them.
I understand the demand for having a proper issue tracker and proper merge requests. But splitting the information in two places is a no no for me and makes the whole situation rather confusing. You would have two sources of truth for the AUR package from my understanding, one in an external Git host and one on aur.archlinux.org.
+1, tried it, doesn't work well. Bjoern:
I fear that this would lead to discussions why some TU decided which PKGBUILD is better.
+1, probably likely to cause conflict. Samuele:
(Hi there, it's my first mailing list post ever)
Welcome to the Arch Linux Mailing list, I hope you enjoy your stay :)
Maybe the solution could be a multi-PKGBUILD system where you can choose which one to use, based on various criteria However, I am afraid that this would be very difficult to implement as a solution
Would be confusing, and also likely to cause conflict and fighting over the better PKGBUILD.
I'm subscribed with my univeristy outlook
I am not sure about your University, but mailing lists can get quite busy and can take up a large amount of storage on the email server (along with a small amount of bandwidth), your University might get annoyed if you are receiving too many emails. Just a heads up, if you checked and they don't care then obviously ignore me, but I know with mine, my email is meant for internal communication and not so much with use of public mailing lists, and I would likely get in trouble :) Plus, I have my own email server, so its not like I want to use any other email than my own :P Rein:
Typically one would just make a patch file and link to it in a comment. Even if the owner does not apply it themselves others can choose to.
+1, has the most flexibility.
An upstream maintainer can just ask to be a co-maintainer of the downstream AUR package.
If a maintainer does not respond, that is already a reason to orphan the package. Thus the only problematic situation I could think of is where a maintainer does communicate but is not willing to fix an issue with their package, which I have never seen myself.
I think it's good not to overcomplicate the system. I don't think the same software should be provided by multiple PKGBUILDs or maintainers. All software should just be packaged correctly on the AUR.
+1, if it is isn't broke, why change it? tippfehlr:
Is there a way to “disown” packages in GitLab, e.g. remove push permission from the repository owner and assign it to the new maintainer (or assign a new owner to the repository)?
If yes, the AUR could be a group in GitLab (like Morten mentioned), which would also put the AUR in a place closer to the official repositories, providing examples of good PKGBUILD files.
I am sure there could be some way of getting Gitlab to reproduce this logic, but what would be the point? See my response to Morten on this. Óscar:
That's the point.
What the AUR really lacks is precisely this. A complete system of merge requests and issues, so that the packages are really projects in which anyone can collaborate at any given time.
You could bring the AUR into your own GitLab instance, but it would require some development to make it work as an AUR. Another option would be to do the same but instead of using a full instance, create an AUR group in the current GitLab, but this would require the aforementioned development and would need something to handle permissions so that users cannot modify each other's repositories.
Implementing other solutions would be, IMHO, too much of a stretch when with GitLab you have practically everything done. However, the customization layer that you have to put on top of it to make it work as an AUR is not going to be easy to do.
-1. I feel that people slap complex frontends onto issues and call it a day. Personally, if I was a package maintainer (arch staff) I would hate the move to gitlab, having to juggle issues and pull requests over build scripts? Come on... it might be useful when you have a gigantic codebase to have lots of features, but these are build scripts which rarely exceed 100 lines... It is already overwhelming to deal with comments, and flags out of dates, then you want me to check issues and pull requests? Like I said, I tried this system, I got completely overwhelmed. Overall I feel the issue here is not the frontend people use, but communication. It seems like there is a vie for control over packages, instead of it being a hobby and being able to contribute, it feels like a full time job where people are trying to show how many packages they can maintain. I have seen it, on the mailing list, in the IRC channels, on social media, how package maintainers brag about how many packages they maintain, "oh I maintain 200 packages, you only maintain 7, I am better than you" kind of logic. I don't know about you, but I sure don't want to work with people who make me feel small and insignificant. Everyone is doing their own thing and instead of people coming together and discussing it like they used to (1 year ago it was much more common to see, "Hey could you review my PKGBUILD" on aur-general), it has turned into taking jabs at each other and spamming orphan requests, instead of trying to help out. It feels like people see alpine, NixOS and Void Linux, and see "Oh they all do it this way, and Arch doesn't, Arch needs to be fixed". Arch is its own thing... you have one file to maintain, .SRCINFO is generated, and a keys directory for PGP keys. Why would you need anything more than a comment section on this? It feels disconnected, and it feels like everyone has THEIR way of doing things, and Evan you brought this up yourself, how there seems to be no standard way of doing stuff, and binary packages being everywhere from debian and fedora, I don't think this is a lack of software frontend, but a lack of communication. There was a few times when I maintained packages where I wouldn't even be contacted, and just whacked with an orphan request because someone wanted the package. I know there was a few packages I held onto for too long, but they are not the issue. I will admit outright, I was far from good at maintaining packages, and I struggled to keep up with flags out of date, I didn't want to bump a package unless I knew for sure the new version worked, which could take a long amount of time, but it doesn't feel people want it, it feels people want instant bumping of packages, and then to moan when it breaks, which is probably why there is a constant desire for autobumping. I no longer maintain packages, so take what you want from this, but there is a reason I quit, and it wasn't a bad frontend or any issue with the AUR itself. I hope if I do want to maintain packages again I don't load the AUR to 50 different tabs I got to watch in case there is a PR, or an issue, or a comment, or an email, you get the point. I hope if there is a plan to change the AUR, that the community at least gets the opportunity to vote, seen as its the user repository and not the staff repository. Sometimes simple is just better, and if you axe the AUR, whats next? Migrating away from IRC because that doesn't have enough modern features? Then remove the mailing lists too because they are not easy to use, use issue section on gitlab instead of a mailing list. You see? You open the biggest can of worms you can imagine when you start using the lack of feature argument against the AUR. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev [1] https://wiki.archlinux.org/title/Unofficial_user_repositories