[aur-general] pkgrel updates
Hi TUs,
I was looking at the pkg_diff page in order to build some packages for community64 and noticed something I found a bit worrying and after much thought, I decided to bring it up. It could all be entirely legitimate and if so I apologize.
A large portion of recent updates (~2/3) are only bumped in the pkgrel, i.e. no pkgver update. While I realize some of these will be legitimate rebuilds, it is a bit of a concern to me given nothing major has moved from the testing repo and I don't recognize the packages from bug reports.
I haven't looked at whose packages these are (and at this stage, I honestly don't care), but it seems a reminder about quality control on the packaging front is needed. I don't mean to sound overly grumpy, but this costs users and the mirrors bandwidth as well as giving the few x86_64 using TUs more work.
I really don't like writing emails like this. We can all make good packages or else we wouldn't be TUs. So please double check your packages before uploading them.
Regards, Allan
On Tue, 20 May 2008 22:36:26 +1000 Allan McRae mcrae_allan@hotmail.com wrote:
A large portion of recent updates (~2/3) are only bumped in the pkgrel, i.e. no pkgver update. While I realize some of these will be legitimate rebuilds, it is a bit of a concern to me given nothing major has moved from the testing repo and I don't recognize the packages from bug reports.
I haven't looked at whose packages these are (and at this stage, I honestly don't care), but it seems a reminder about quality control on the packaging front is needed. I don't mean to sound overly grumpy, but this costs users and the mirrors bandwidth as well as giving the few x86_64 using TUs more work.
I would have thought this phenomenon would be a result of quality control, not a lack of it. A pkgrel might be bumped as a result of making a PKGBUILD more standards compliant for example. Anyways, you have a point. It's not nice to to make users download/install the same pkg for only that reason.
Is it still possible to upload a new PKGBUILD without uploading a new binary package so that ABS users get the good stuff? That might be handy.
On Tue, 20 May 2008, Loui wrote:
Is it still possible to upload a new PKGBUILD without uploading a new binary package so that ABS users get the good stuff? That might be handy.
Yes, it's possible. Just tag and commit the PKGBUILD in cvs. Details are in the wiki articles linked from AUR home page. However, if you do that, don't change the pkgrel otherwise you'll break the community db with the well known "missing package" error.
Hi, 2008/5/20 Allan McRae mcrae_allan@hotmail.com:
A large portion of recent updates (~2/3) are only bumped in the pkgrel, i.e. no pkgver update. While I realize some of these will be legitimate rebuilds, it is a bit of a concern to me given nothing major has moved from the testing repo and I don't recognize the packages from bug reports.
For fix FS#9970 bug report, I added license to many packages. Thus I've rebuilt the packages.
Sorry for the inconvenience but I thought it must be made.
I'm on i686 architecture thus I can't fix lib32* packages.
Please see the list of packages without license(), some of these require fix for gcc4.3 and maybe can be moved to unsupported because are unmaintained.
Regards, Andrea
On Tue, 20 May 2008 20:56:48 +0200 BaSh bash.lnx@gmail.com wrote:
Hi, 2008/5/20 Allan McRae mcrae_allan@hotmail.com:
[cut]
Please see the list of packages without license(), some of these require fix for gcc4.3 and maybe can be moved to unsupported because are unmaintained.
You could made a new list about it.
And, sorry, in my point of view bumping pkgrel and upload a package is necessary when we're doing an important modification like changing / adding licenses.
Is there anyone of us that could set-up a temporary building machine?
On the point that who upload packages without a license isn't a good TU, I'm with you.
2008/5/20 JJDaNiMoTh jjdanimoth@gmail.com:
On Tue, 20 May 2008 20:56:48 +0200 You could made a new list about it.
You can see the updated list in my comment into the bug report.
Anyway I attach the list at this mail.
On the point that who upload packages without a license isn't a good TU, I'm with you.
Thanks ;)
Cheers
On the point that who upload packages without a license isn't a good TU, I'm with you.
-- JJDaNiMoTh - ArchLinux Trusted User
yes I'm a bit disappointed too. Almost two months have passed since I wrote the script and created the initial list, though very little did happen until BaSh started to add the licenses (thanks for that btw). I originally created the list though, so that each and every TU who has packages in that list could fix his own packages.
For the ones who did fix their own packages or have a legitimate reason no to do so that's okay, but I really have to say for all other TUs, licenses are important. The field is there for a reason so please use it. If you don't have time to fix things yourself, send a mail to aur-general and ask someone with more time to do so. I hope that is not too much to ask? (I hope I don't sound too angry because I'm not, I just want you all to take my point :p)
Thank you.
2008/5/20 Ronald van Haren pressh@gmail.com:
yes I'm a bit disappointed too. Almost two months have passed since I wrote the script and created the initial list, though very little did happen until BaSh started to add the licenses (thanks for that btw). I originally created the list though, so that each and every TU who has packages in that list could fix his own packages.
I thought what 2 months are lot of time for a little fix like as add license() at PKGBUILDs. Thus yesterday I started to fix the PKGBUILDs and today I finished to do it. I fixed maybe 30~35 packages (more are maintained by dtw). Now I sent a new list of packages and please everyTU see that list and fix own packages.
Regards
2008/5/20 BaSh bash.lnx@gmail.com:
2008/5/20 Ronald van Haren pressh@gmail.com:
yes I'm a bit disappointed too. Almost two months have passed since I
[cut]
Thus yesterday I started to fix the PKGBUILDs and today I finished to do it. I fixed maybe 30~35 packages (more are maintained by dtw).
dtw is a TU or not?
If not, we could move some packages to unsupported; if yes, it's time to call a removing vote.
DaNiMoTh wrote:
2008/5/20 BaSh bash.lnx@gmail.com:
2008/5/20 Ronald van Haren pressh@gmail.com:
yes I'm a bit disappointed too. Almost two months have passed since I
[cut]
Thus yesterday I started to fix the PKGBUILDs and today I finished to do it. I fixed maybe 30~35 packages (more are maintained by dtw).
dtw is a TU or not?
If not, we could move some packages to unsupported; if yes, it's time to call a removing vote.
In fact, dtw is a dev. As far as I can tell, he has been on an extended absence for the past year but does pop his head up occasionally.
I am not sure what to do in that case. But if anyone want to take one of his out of date packages, then I say feel free. I know some of them have already been taken by other TUs...
Allan
2008/5/21 DaNiMoTh jjdanimoth@gmail.com:
dtw is a TU or not?
If not, we could move some packages to unsupported; if yes, it's time to call a removing vote.
I think isn't necessary move dtw's packages to unsupported, there are 2 new TU (gcarrier, Drag0nlord) and they can adopt dtw's packages.
I'm agree to start removal vote.
Regards
2008/5/21 BaSh bash.lnx@gmail.com:
2008/5/21 DaNiMoTh jjdanimoth@gmail.com:
dtw is a TU or not?
If not, we could move some packages to unsupported; if yes, it's time to call a removing vote.
I think isn't necessary move dtw's packages to unsupported, there are 2 new TU (gcarrier, Drag0nlord) and they can adopt dtw's packages.
I'm agree to start removal vote.
Hehe, you cannot start a removal voting, because dtw is not a TU since he resigned after becoming a dev. ;-) (that was on 6th of July, 2007).
He still has some packages in community (last time he given out some of them) (some of which I was going to maintain, but became unable to do this... :-()
So, I'd say that people who want to take his packages contact him personally, so this just wouldn't become a surprise for him.
2008/5/21 Roman Kyrylych roman.kyrylych@gmail.com:
Hehe, you cannot start a removal voting, because dtw is not a TU since he resigned after becoming a dev. ;-) (that was on 6th of July, 2007).
He still has some packages in community (last time he given out some of them) (some of which I was going to maintain, but became unable to do this... :-()
So, I'd say that people who want to take his packages contact him personally, so this just wouldn't become a surprise for him.
-- Roman Kyrylych (Роман Кирилич)
Did anyone contact me personally? I was surprised!
Full marks for enthusiasm, guys and gals, and thank you for keeping "my" pkgs up to date.
I say "my" because one thing I always disliked about this pkg maintenance business was the sense of ownership and I had hoped after my absence I would not feel so attached to "my" pkgs but I do! I miss you geany! *sob*
However, I'm not asking for any of them "back" but if it's more convenient for my remaining pkgs (i.e. deps) I might contact people about readopting some of them.
I also might move some of the more mature and popular pkgs to [extra] depending on the situation there.
Cheers and thanks again
dtw
BaSh wrote:
Hi, 2008/5/20 Allan McRae mcrae_allan@hotmail.com:
A large portion of recent updates (~2/3) are only bumped in the pkgrel, i.e. no pkgver update. While I realize some of these will be legitimate rebuilds, it is a bit of a concern to me given nothing major has moved from the testing repo and I don't recognize the packages from bug reports.
For fix FS#9970 bug report, I added license to many packages. Thus I've rebuilt the packages.
Sorry for the inconvenience but I thought it must be made.
I'm on i686 architecture thus I can't fix lib32* packages.
Please see the list of packages without license(), some of these require fix for gcc4.3 and maybe can be moved to unsupported because are unmaintained.
OK, so this was the cause. I would have just committed the change to CVS without a pkgrel update. But anyway, it is good to know there is an explanation because I was slightly concerned about what was going on.
Note it is much better if the actual maintainer fixes their own packages because you know they are going to work from their local copy (without this change) when they update the package again...
Allan
On Wed, 21 May 2008 06:02:44 +1000 Allan McRae mcrae_allan@hotmail.com wrote:
BaSh wrote:
[cut]
Note it is much better if the actual maintainer fixes their own packages
This is right.
because you know they are going to work from their local copy (without this change) when they update the package again...
A cvs update is the best thing to do before any modifications, because if you work on pkgbuild outdated you can't upload it.
2008/5/20 Allan McRae mcrae_allan@hotmail.com:
OK, so this was the cause. I would have just committed the change to CVS without a pkgrel update. But anyway, it is good to know there is an explanation because I was slightly concerned about what was going on.
Note it is much better if the actual maintainer fixes their own packages because you know they are going to work from their local copy (without this change) when they update the package again...
This is true, but I think the PKGBUILDs without license(), in some case, are old projects thus maybe not there will be a next release.
Regards, Andrea
participants (9)
-
Allan McRae
-
BaSh
-
DaNiMoTh
-
Eric Belanger
-
JJDaNiMoTh
-
Loui
-
Phil Dillon-Thiselton
-
Roman Kyrylych
-
Ronald van Haren