[aur-general] AUR4 migration of orphan packages
Hi, There are a lot of orphan packages that haven't been updated for months or years, but still work fine and could be considered useful. I understand that these packages will still be available even if nobody port them. However I don't know if the current AUR helpers will be able to see them or if they will be updated for this purpose. If not, I would be happy to adopt some of these packages to do the transition, even if I may disown most of them shortly after. I suppose that adapting the tooling (if needed) would be a better approach, but if they don't consider to do it I would find it sad to let all these packages sink into oblivion. Simon
* Simon Brulhart <simon@brulhart.me> [2015-06-09 11:36:09 +0200]:
There are a lot of orphan packages that haven't been updated for months or years, but still work fine and could be considered useful. I understand that these packages will still be available even if nobody port them. However I don't know if the current AUR helpers will be able to see them or if they will be updated for this purpose. If not, I would be happy to adopt some of these packages to do the transition, even if I may disown most of them shortly after.
I suppose that adapting the tooling (if needed) would be a better approach, but if they don't consider to do it I would find it sad to let all these packages sink into oblivion.
I agree! It'd be helpful to see the archived old-AUR packages somewhere in AUR helpers, marked accordingly, so one can easily discover and adopt them even after the AUR transition is done. For yaourt[*], I opened an issue here yesterday: https://github.com/archlinuxfr/yaourt/issues/115 I don't think just porting and then disowning packages is the right thing to do - then the new AUR will be cluttered with things nobody cares about again. If you care enough to want a package ported (e.g. because you use it and it's currently orphaned), you should care enough to adopt it, IMHO. :) Florian [*] Just to preempt this: I hope it won't be necessary to mention this, but I use yaourt since I use Arch (>5 years), I'm still happy with it, and yes - I know how to use makepkg manually. If you really feel like discussing about yaourt instead of the rest of the mail, please do so with a personal reply, not to the ML. Thanks! -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
Simon Brulhart <simon@brulhart.me> [2015-06-09 11:36:09 +0200]:
There are a lot of orphan packages that haven't been updated for months or years, but still work fine and could be considered useful.
Considered useful by whom? We don't need them around because they *might* be useful to some hypothetical person in some hypothetical situation. On Tue, Jun 09, 2015 at 11:45:30AM +0200, Florian Bruhin wrote:
If you care enough to want a package ported (e.g. because you use it and it's currently orphaned), you should care enough to adopt it, IMHO. :)
Agreed. All the packages that no one carries over to aur4 will still be archived for some time, so if anyone *actually* wants them in aur4, they can adopt them. One can keep their own store of PKGBUILDs, but the aur is for packages that it is likely multiple users will want. If not even *one* person wants a package enough to maintain it in the aur, then it doesn't need to be there. -Jesse AKA 'Trilby' on archlinux.org
On 09-06-2015 08:17, Jesse McClure wrote:
Agreed. All the packages that no one carries over to aur4 will still be archived for some time, so if anyone*actually* wants them in aur4, they can adopt them. One can keep their own store of PKGBUILDs, but the aur is for packages that it is likely multiple users will want. If not even*one* person wants a package enough to maintain it in the aur, then it doesn't need to be there. I have adopted some packages, created a few more, but I think that this migration should serve the purpose of cleansing the database. We already have orphans on aur4 and that is unacceptable. Migrate a package and then orphan it is not ideal and we will end up having the same number of orphans as we already have.
Cheers, Giancarlo Razzolini
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is: Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns. It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite "orphaned"? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.) I do something in between outright maintainership and this "adopt, update, disown" non-maintainership: I have a git repo with my AUR packages, and accept pull requests on GitHub -- if someone wants to update a package faster than I can get to it (since I only have time on weekends), they submit a pull request and I merge it in, test, and submit to AUR (which takes 2 min to verify & submit the package, vs. the a-priori-unknown time commitment of doing it all myself). It would be nice if there were an official way to make AUR support collaborative maintainership like this. On Tue, Jun 9, 2015 at 11:10 AM, Giancarlo Razzolini <grazzolini@gmail.com> wrote:
On 09-06-2015 08:17, Jesse McClure wrote:
Agreed. All the packages that no one carries over to aur4 will still be archived for some time, so if anyone*actually* wants them in aur4, they can adopt them. One can keep their own store of PKGBUILDs, but the aur is for packages that it is likely multiple users will want. If not even*one* person wants a package enough to maintain it in the aur, then it doesn't need to be there.
I have adopted some packages, created a few more, but I think that this migration should serve the purpose of cleansing the database. We already have orphans on aur4 and that is unacceptable. Migrate a package and then orphan it is not ideal and we will end up having the same number of orphans as we already have.
Cheers, Giancarlo Razzolini
You mean that: https://aur4.archlinux.org/pkgbase/${pkgname}/comaintainers/ ? Le 09/06/2015 17:53, Ido Rosen a écrit :
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is:
Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns.
It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite "orphaned"? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.)
I do something in between outright maintainership and this "adopt, update, disown" non-maintainership: I have a git repo with my AUR packages, and accept pull requests on GitHub -- if someone wants to update a package faster than I can get to it (since I only have time on weekends), they submit a pull request and I merge it in, test, and submit to AUR (which takes 2 min to verify & submit the package, vs. the a-priori-unknown time commitment of doing it all myself). It would be nice if there were an official way to make AUR support collaborative maintainership like this.
On Tue, Jun 9, 2015 at 11:10 AM, Giancarlo Razzolini <grazzolini@gmail.com> wrote:
On 09-06-2015 08:17, Jesse McClure wrote:
Agreed. All the packages that no one carries over to aur4 will still be archived for some time, so if anyone*actually* wants them in aur4, they can adopt them. One can keep their own store of PKGBUILDs, but the aur is for packages that it is likely multiple users will want. If not even*one* person wants a package enough to maintain it in the aur, then it doesn't need to be there. I have adopted some packages, created a few more, but I think that this migration should serve the purpose of cleansing the database. We already have orphans on aur4 and that is unacceptable. Migrate a package and then orphan it is not ideal and we will end up having the same number of orphans as we already have.
Cheers, Giancarlo Razzolini
I didn't know that existed! Cool. Maybe this should be front and center next to any links/buttons to disown a package? E.g. "Are you sure you want to disown this package? Remember, you can always add co-maintainers rather than disowning and readopting later..." On Tue, Jun 9, 2015 at 11:59 AM, Bruno Pagani <bruno.pagani@ens-lyon.org> wrote:
You mean that: https://aur4.archlinux.org/pkgbase/${pkgname}/comaintainers/ ?
Le 09/06/2015 17:53, Ido Rosen a écrit :
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is:
Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns.
It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite "orphaned"? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.)
I do something in between outright maintainership and this "adopt, update, disown" non-maintainership: I have a git repo with my AUR packages, and accept pull requests on GitHub -- if someone wants to update a package faster than I can get to it (since I only have time on weekends), they submit a pull request and I merge it in, test, and submit to AUR (which takes 2 min to verify & submit the package, vs. the a-priori-unknown time commitment of doing it all myself). It would be nice if there were an official way to make AUR support collaborative maintainership like this.
On Tue, Jun 9, 2015 at 11:10 AM, Giancarlo Razzolini <grazzolini@gmail.com> wrote:
On 09-06-2015 08:17, Jesse McClure wrote:
Agreed. All the packages that no one carries over to aur4 will still be archived for some time, so if anyone*actually* wants them in aur4, they can adopt them. One can keep their own store of PKGBUILDs, but the aur is for packages that it is likely multiple users will want. If not even*one* person wants a package enough to maintain it in the aur, then it doesn't need to be there. I have adopted some packages, created a few more, but I think that this migration should serve the purpose of cleansing the database. We already have orphans on aur4 and that is unacceptable. Migrate a package and then orphan it is not ideal and we will end up having the same number of orphans as we already have.
Cheers, Giancarlo Razzolini
I think the new AUR4 indeed have a co-maintainer list for each package. It is just in the package actions panel. (Although I haven't try this feature) On Wed, Jun 10, 2015 at 12:53 AM, Ido Rosen <ido@kernel.org> wrote:
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is:
Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns.
It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite "orphaned"? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.)
I do something in between outright maintainership and this "adopt, update, disown" non-maintainership: I have a git repo with my AUR packages, and accept pull requests on GitHub -- if someone wants to update a package faster than I can get to it (since I only have time on weekends), they submit a pull request and I merge it in, test, and submit to AUR (which takes 2 min to verify & submit the package, vs. the a-priori-unknown time commitment of doing it all myself). It would be nice if there were an official way to make AUR support collaborative maintainership like this.
On Tue, Jun 9, 2015 at 11:10 AM, Giancarlo Razzolini <grazzolini@gmail.com> wrote:
On 09-06-2015 08:17, Jesse McClure wrote:
Agreed. All the packages that no one carries over to aur4 will still be archived for some time, so if anyone*actually* wants them in aur4, they can adopt them. One can keep their own store of PKGBUILDs, but the aur is
for
packages that it is likely multiple users will want. If not even*one* person wants a package enough to maintain it in the aur, then it doesn't need to be there.
I have adopted some packages, created a few more, but I think that this migration should serve the purpose of cleansing the database. We already have orphans on aur4 and that is unacceptable. Migrate a package and then orphan it is not ideal and we will end up having the same number of orphans as we already have.
Cheers, Giancarlo Razzolini
-- -------------------------------------------------------------------------------- Jiachen Yang 楊嘉晨 Graduate School of Information Science and Technology, Osaka University Tel: 080-3853-2770 MSN: firechildren@hotmail.com GMail: farseerfc@gmail.com
Am Dienstag, 9. Juni 2015, 11:53:53 schrieb Ido Rosen:
It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite "orphaned"? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.)
According to the AUR4 webui it is possible to specify co-maintainers for a pkg (if you own a pkg, you'll find the button next to the disown button). But I actually like the idea of using git for non-co-maintainers to contribute: I assume that only the master branch is used for the actual pkg - so if we allow any user to update every branch (but the master branch) of every package, we could have something similar to pull requests. A user could just submit his patch into a new branch and the actual maintainer can simply merge it into master.
On Tue, Jun 9, 2015 at 5:53 PM, Ido Rosen <ido@kernel.org> wrote:
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is:
Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns.
It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite "orphaned"? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.)
It also prevents a third party (Mallory) from taking it over and: (a) replacing it with something else (malware?); (b) preventing Alice and Bob from updating it; (c) requesting deletion; (d) [insert other harmful actions here].
if someone wants to update a package faster than I can get to it […]
You should use some service that would tell you about package updates, for example requires.io for Python, or RSS feeds. Will take 5 minutes to do it in many cases (to update pkgver and the checkums) -- Chris Warrick <https://chriswarrick.com/> PGP: 5EAAEA16
On Tue, Jun 9, 2015 at 12:14 PM, Chris Warrick <kwpolska@gmail.com> wrote:
On Tue, Jun 9, 2015 at 5:53 PM, Ido Rosen <ido@kernel.org> wrote:
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is:
Person A adopts, updates, and disowns. Person B some time later notices it's out of date, adopts, updates, disowns.
It seems perfectly reasonable to have multiple people maintain a package over time this way. Maybe we just need better support for this style of non-maintainership that isn't quite "orphaned"? Support for multiple maintainers/collaborators like on GitHub repos? (Outright owning a package in AUR prevents anyone else from updating it.)
It also prevents a third party (Mallory) from taking it over and:
(a) replacing it with something else (malware?); (b) preventing Alice and Bob from updating it; (c) requesting deletion; (d) [insert other harmful actions here].
Yes, that's right, and these are all good reasons why we should continue to have ownership, which is why I suggested we support something in-between as well (before I knew about co-maintainership capabilities in AUR, which basically resolve this).
if someone wants to update a package faster than I can get to it […]
You should use some service that would tell you about package updates, for example requires.io for Python, or RSS feeds. Will take 5 minutes to do it in many cases (to update pkgver and the checkums)
Thanks for the suggestion, but these services don't work for some (or most) of the packages I maintain, and some of the packages are academic in nature. For updates that are just updating the pkgver & updpkgsums, I do those myself, but there are cases (major version changes, new feature requests, upstream breaks something, dependent packages break something, etc.) where debugging/more time is needed. That's when it may take me a week or more to get around to updating the package, in which case if someone else with more time gets to it sooner, I encourage them to submit a pull request and add them as a Contributor: (and thank them for helping!). :-) Another thing that having the pull request workflow I use allows is for the users of the package to add things to the package (e.g. optdepends as they come out) and fix bugs. It makes my work after initially creating the package basically just QA to make sure their PRs don't break anything in many cases, which I like.
-- Chris Warrick <https://chriswarrick.com/> PGP: 5EAAEA16
On Tue, 9 Jun 2015 18:14:58 +0200 Chris Warrick <kwpolska@gmail.com> wrote:
On Tue, Jun 9, 2015 at 5:53 PM, Ido Rosen <ido@kernel.org> wrote:
I think some of the orphans on AUR are just maintained by multiple people. The usage pattern is:
IMO, it would be a lot better for the distro to get rid of badly packaged software instead of cleaning out orphans (that may or may not be up to date and/or useful to many users)... Sadly I have no bright idea for how to bring this about :) -- Joakim
participants (10)
-
Bruno Pagani
-
Chris Warrick
-
Dominik Heidler
-
Florian Bruhin
-
Giancarlo Razzolini
-
Ido Rosen
-
Jesse McClure
-
Jiachen Yang
-
Joakim Hernberg
-
Simon Brulhart