[arch-dev-public] Code review: dbscripts
So I made a handful of changes to the dbscripts, and wanted to get a quick review from people before I push them live. If you get a chance, please look over the recent patches here: http://projects.archlinux.org/?p=dbscripts.git;a=summary This include's Xavier's new-and-improved check_archlinux script too. Thanks, Aaron :wq
Aaron Griffin schrieb:
So I made a handful of changes to the dbscripts, and wanted to get a quick review from people before I push them live.
If you get a chance, please look over the recent patches here: http://projects.archlinux.org/?p=dbscripts.git;a=summary
This include's Xavier's new-and-improved check_archlinux script too.
Thanks, Aaron :wq
Starting to review your changes now. Could we please tag the "releases" that are used on gerolde in the future? I was guessing that f404689fc11bbeace243779305ede5b7d7270ae8 is what we are using now but it seems that there is a commit in /arch/.git which is not on the projects.archlinux repo. What's wrong here?
On Sun, Aug 31, 2008 at 3:18 AM, Thomas Bächler
Aaron Griffin schrieb:
So I made a handful of changes to the dbscripts, and wanted to get a quick review from people before I push them live.
If you get a chance, please look over the recent patches here: http://projects.archlinux.org/?p=dbscripts.git;a=summary
This include's Xavier's new-and-improved check_archlinux script too.
Thanks, Aaron :wq
Starting to review your changes now. Could we please tag the "releases" that are used on gerolde in the future?
I was guessing that f404689fc11bbeace243779305ede5b7d7270ae8 is what we are using now but it seems that there is a commit in /arch/.git which is not on the projects.archlinux repo. What's wrong here?
Yup, I will tag them when I push them live from now on, I realized this too. About that straggling commit... I guess I never pushed it, like an idiot 8( I will re-add it to the projects tree... my fault
On Sun, Aug 31, 2008 at 4:24 AM, Aaron Griffin
So I made a handful of changes to the dbscripts, and wanted to get a quick review from people before I push them live.
If you get a chance, please look over the recent patches here: http://projects.archlinux.org/?p=dbscripts.git;a=summary
About this commit : Create a "common functions" file for DB scripts I don't see where the db-functions file was created.
This include's Xavier's new-and-improved check_archlinux script too.
Cool, I hope you will get it working :)
Aaron Griffin schrieb:
So I made a handful of changes to the dbscripts, and wanted to get a quick review from people before I push them live.
If you get a chance, please look over the recent patches here: http://projects.archlinux.org/?p=dbscripts.git;a=summary
This include's Xavier's new-and-improved check_archlinux script too.
Thanks, Aaron :wq
I didn't look at check_archlinux, as it's too long for me now: http://projects.archlinux.org/?p=dbscripts.git;a=commit;h=909b017c08109bda40... Now my remarks on the rest: http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=afc6b5b5977fe7... The db-functions has not been added here, so I can't really check if it is fine, the rest looks good though. http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=06194a8691f50f... There is a problem here: rm -f "$srcpath/${pkgname}-*-*${SRCEXT}" If you run this with mplayer, this will not only remove old mplayer packages, but also mplayer-plugin (think of more examples if you want). That's the reason I am using the ugly getpkgname in the cleanup scripts (or was using it, dunno if it is still there). http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=e1ad729fd49c63... This includes unstable and lacks community. Couldn't see more problems now, but there probably are more.
On Sun, Aug 31, 2008 at 10:49 AM, Thomas Bächler
I didn't look at check_archlinux, as it's too long for me now: http://projects.archlinux.org/?p=dbscripts.git;a=commit;h=909b017c08109bda40...
A simple testing could be useful. Anyway, this is much less important than the rest since it is only a abs/PKGBUILD checker, so nothing bad should happen even if it does not work correctly.
On Sun, Aug 31, 2008 at 3:49 AM, Thomas Bächler
http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=afc6b5b5977fe7... The db-functions has not been added here, so I can't really check if it is fine, the rest looks good though.
Oh man, my fault. Committed and pushed now. The big issue here is that I was stupidly locking some of the things NOT based on the repo, but based on the script. I wanted to unify the locking so that db-remove will fail for a repo that has a db-update in progress, etc
http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=06194a8691f50f... There is a problem here: rm -f "$srcpath/${pkgname}-*-*${SRCEXT}" If you run this with mplayer, this will not only remove old mplayer packages, but also mplayer-plugin (think of more examples if you want). That's the reason I am using the ugly getpkgname in the cleanup scripts (or was using it, dunno if it is still there).
That's a very good point. Could you suggest a cleaner way to clean up existing tarballs? How about: for srcpkg in $pkgname*; do [ "$(getpkgname $srcpkg)" == "$pkgname" ] && rm -f "$srcpkg" done
http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=e1ad729fd49c63... This includes unstable and lacks community.
Removed unstable... community, however, is another beast that I wanted to avoid thinking about for now... adding that might tip us over the disk space limit on gerolde. For the record, I have not moved existing source tarballs to /home/ftp/sources/ yet, because I fear it may force our mirrors to sync those as well... does anyone with more rsync knowledge want to check to see if this will happen? I'd like to add a stanza for JUST the sources and exclude if from elsewhere, making it optional...
Aaron Griffin schrieb:
http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=06194a8691f50f... There is a problem here: rm -f "$srcpath/${pkgname}-*-*${SRCEXT}" If you run this with mplayer, this will not only remove old mplayer packages, but also mplayer-plugin (think of more examples if you want). That's the reason I am using the ugly getpkgname in the cleanup scripts (or was using it, dunno if it is still there).
That's a very good point. Could you suggest a cleaner way to clean up existing tarballs? How about: for srcpkg in $pkgname*; do [ "$(getpkgname $srcpkg)" == "$pkgname" ] && rm -f "$srcpkg" done
That should work, if we make sure the getpkgname function parses the filename properly.
http://projects.archlinux.org/?p=dbscripts.git;a=commitdiff;h=e1ad729fd49c63... This includes unstable and lacks community.
Removed unstable... community, however, is another beast that I wanted to avoid thinking about for now... adding that might tip us over the disk space limit on gerolde.
I thought we had enough donation money left, if so, just get another hard drive.
For the record, I have not moved existing source tarballs to /home/ftp/sources/ yet, because I fear it may force our mirrors to sync those as well... does anyone with more rsync knowledge want to check to see if this will happen? I'd like to add a stanza for JUST the sources and exclude if from elsewhere, making it optional...
Depends on what they sync. The "ftp" module contains "exclude = /archive/ /other/", while the "ftpfull"/"kitchensink" module doesn't have an exclude line. We could add exclude = /sources to kitchensink, ftpfull and ftp, so that they'd have to explicitly sync the "sources" module.
Removed unstable... community, however, is another beast that I wanted to avoid thinking about for now... adding that might tip us over the disk space limit on gerolde.
I thought we had enough donation money left, if so, just get another hard drive.
Sounds like an easy solution until you realize there are no free drive bays on gerolde... We'd have to upgrade the current disks instead of adding more. Dale
participants (4)
-
Aaron Griffin
-
Dale Blount
-
Thomas Bächler
-
Xavier