[aur-general] community repo "cleanup"
Hi, I was thinking that it has been almost a year since the [community] repo switched to using the main db-scripts, but there are still a large number of packages without the package architecture in their name (the old scripts removed it). It is somewhere around 1/3 of the repo (anything build before 2009-07-14). In fact, one package (datemath) was built back in 2005! Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place such as: - get the package architecture in the file name - build with new toolchain, CFLAGS, LDFLAGS etc - compress with .xz format - convert to arch=any as necessary - $startdir usage - package() functions - ... It would also be a good time to remove old packages that are really no longer of interest from the repo. What do people think? I can create an internal TODO list for these packages that can be slowly worked through. Allan
Am 19.05.2010 06:59, schrieb Allan McRae:
Hi,
I was thinking that it has been almost a year since the [community] repo switched to using the main db-scripts, but there are still a large number of packages without the package architecture in their name (the old scripts removed it). It is somewhere around 1/3 of the repo (anything build before 2009-07-14). In fact, one package (datemath) was built back in 2005!
Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place such as: - get the package architecture in the file name - build with new toolchain, CFLAGS, LDFLAGS etc - compress with .xz format - convert to arch=any as necessary - $startdir usage - package() functions - ...
It would also be a good time to remove old packages that are really no longer of interest from the repo.
What do people think? I can create an internal TODO list for these packages that can be slowly worked through.
Allan
Good idea! Go ahaead!
Hi,
I was thinking that it has been almost a year since the [community] repo switched to using the main db-scripts, but there are still a large number of packages without the package architecture in their name (the old scripts removed it). It is somewhere around 1/3 of the repo (anything build before 2009-07-14). In fact, one package (datemath) was built back in 2005!
Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place such as: - get the package architecture in the file name - build with new toolchain, CFLAGS, LDFLAGS etc - compress with .xz format - convert to arch=any as necessary - $startdir usage - package() functions - ...
It would also be a good time to remove old packages that are really no longer of interest from the repo.
What do people think? I can create an internal TODO list for these packages that can be slowly worked through.
Allan
This sounds good to me. I have a suggestion that might increase overall productivity by making cooperation easier. Create a dedicated directory for this on Sigurd, e.g. "rebuilds". We can all mount this using sshfs which will ensure that each of us is using the latest lists etc and thus avoid redundancy without having to edit and refresh the bug tracker. Create the following directories: rebuilds/unsorted/ rebuilds/pending/ rebuilds/staging/ rebuilds/complete/ "unsorted" will contain the current PKGBUILDs and local source files, e.g. "rebuilds/pending/foo/PKGBUILD". "pending" will contain those that will be kept and that have been inspected and possibly updated (e.g. $startdir usage). Considering that most PKGBUILDs will only require minor tweaks, everything in "pending" should be ready for makepkg. The idea is that as packages end up in "pending", others can begin building them without worrying about other architectures. Some will require further tweaks which may even be architecture-specific. This should not be an issue if "pending" is mounted via sshfs because each person will always have the latest version of the PKGBUILD. Simultaneous editing should not be an issue either because any good text editor will detect the changes on the disk. The easiest way to build each package would be to create a local directory named $pkgname and then symlink the PKGBUILD and local source files in it. Again, the symlink runs through SSH so you know you have the latest version of each file. If the package builds successfully, it can be uploaded to "staging". Once a package has been built for each architecture with the same PKGBUILD, it can be moved to "complete". Everything in "complete" can be committed to SVN later. The idea is to avoid dealing with SVN checkouts and commits unnecessarily and to make it possible to build for a given architecture without having to worry about others. This will make it possible for i686-only packagers to work on multi-architecture packages and it will let x86_64 packagers avoid dealing with chroots and virtual machines. I could write scripts to make all of this easier (creating the dir with symlinks, building and moving to staging, checking for "complete" packages, removing old packages after a version bump, etc). I'm just floating the idea though. Xyne
On 19/05/10 20:42, Xyne wrote:
The idea is to avoid dealing with SVN checkouts and commits unnecessarily and to make it possible to build for a given architecture without having to worry about others. This will make it possible for i686-only packagers to work on multi-architecture packages and it will let x86_64 packagers avoid dealing with chroots and virtual machines.
I didn't read the whole proposal as I found it a bit hard to follow (it's kinda late; 9pm :P) and just skimmed through. However, let me note that the above suggestion is bad practice. All packages should ideally be built inside a clean chroot to prevent linking against other libraries that are installed on the system but not explicitly wanted in the package, and to a lesser extent to avoid having missing dependencies (might not apply to rebuilds) or custom {C,LD}FLAGS.
On 20/05/10 03:42, Xyne wrote:
Hi,
I was thinking that it has been almost a year since the [community] repo switched to using the main db-scripts, but there are still a large number of packages without the package architecture in their name (the old scripts removed it). It is somewhere around 1/3 of the repo (anything build before 2009-07-14). In fact, one package (datemath) was built back in 2005!
Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place such as: - get the package architecture in the file name - build with new toolchain, CFLAGS, LDFLAGS etc - compress with .xz format - convert to arch=any as necessary - $startdir usage - package() functions - ...
It would also be a good time to remove old packages that are really no longer of interest from the repo.
What do people think? I can create an internal TODO list for these packages that can be slowly worked through.
Allan
This sounds good to me.
I have a suggestion that might increase overall productivity by making cooperation easier.
Create a dedicated directory for this on Sigurd, e.g. "rebuilds". We can all mount this using sshfs which will ensure that each of us is using the latest lists etc and thus avoid redundancy without having to edit and refresh the bug tracker.
Create the following directories:
rebuilds/unsorted/ rebuilds/pending/ rebuilds/staging/ rebuilds/complete/
"unsorted" will contain the current PKGBUILDs and local source files, e.g. "rebuilds/pending/foo/PKGBUILD".
"pending" will contain those that will be kept and that have been inspected and possibly updated (e.g. $startdir usage). Considering that most PKGBUILDs will only require minor tweaks, everything in "pending" should be ready for makepkg.
The idea is that as packages end up in "pending", others can begin building them without worrying about other architectures. Some will require further tweaks which may even be architecture-specific. This should not be an issue if "pending" is mounted via sshfs because each person will always have the latest version of the PKGBUILD. Simultaneous editing should not be an issue either because any good text editor will detect the changes on the disk.
The easiest way to build each package would be to create a local directory named $pkgname and then symlink the PKGBUILD and local source files in it. Again, the symlink runs through SSH so you know you have the latest version of each file. If the package builds successfully, it can be uploaded to "staging".
Once a package has been built for each architecture with the same PKGBUILD, it can be moved to "complete". Everything in "complete" can be committed to SVN later.
The idea is to avoid dealing with SVN checkouts and commits unnecessarily and to make it possible to build for a given architecture without having to worry about others. This will make it possible for i686-only packagers to work on multi-architecture packages and it will let x86_64 packagers avoid dealing with chroots and virtual machines.
I could write scripts to make all of this easier (creating the dir with symlinks, building and moving to staging, checking for "complete" packages, removing old packages after a version bump, etc).
I'm just floating the idea though.
This seems way too complicated... and I am not sure of the advantages over the current TODO list system. The TODO list which shows when packages are built for only one architecture. So if someone can only build for one Arch, another person already can see the other needing done and do the build. And that should be a non-issue given access to PKGBUILD.com anyway. Also, x86_64 packagers should not need to anything complicated to deal with chroots or VMs to build i686 packages. My only change to build for i686 from x86_64 is to add linux32 in front of the makechrootpkg command. Allan
On 20/05/2010, Allan McRae <allan@archlinux.org> wrote:
This seems way too complicated... and I am not sure of the advantages over the current TODO list system.
The TODO list which shows when packages are built for only one architecture. So if someone can only build for one Arch, another person already can see the other needing done and do the build. And that should be a non-issue given access to PKGBUILD.com anyway.
Also, x86_64 packagers should not need to anything complicated to deal with chroots or VMs to build i686 packages. My only change to build for i686 from x86_64 is to add linux32 in front of the makechrootpkg command.
I think Xyne was concerned about packagers sharing the (architecture) load and conflicting updates, but I believe that is very unlikely to happen. Even when it does, you can just revert your changes and let the previous committer go on to complete the update for both architectures. He can request another packager to build for an arch that he cannot. It will just be like previous major rebuilds, only this time they go to community-testing. And there are 2 slots per arch on PKGBUILD.com with a nice queueing system :) -- GPG/PGP ID: B42DDCAD
On Wed, May 19, 2010 at 12:59 AM, Allan McRae <allan@archlinux.org> wrote:
It would also be a good time to remove old packages that are really no longer of interest from the repo.
if any are perl-* let me know and I'll pick them up on AUR -- Caleb Cushing http://xenoterracide.blogspot.com
On 05/19/10 00:59, Allan McRae wrote:
Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place[...]
I wonder if we should be concerned about the current toolchain? For example GCC 4.5.0 was mis-compiling some things when optimizations were on, if I recall correctly -- an effect that might be magnified by recompiling a lot of rarely-used/tested packages with it. (For example, I suppose we could wait until GCC 4.5.1 before doing a rebuild.) -Isaac
On 20/05/10 09:08, Isaac Dupree wrote:
On 05/19/10 00:59, Allan McRae wrote:
Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place[...]
I wonder if we should be concerned about the current toolchain? For example GCC 4.5.0 was mis-compiling some things when optimizations were on, if I recall correctly -- an effect that might be magnified by recompiling a lot of rarely-used/tested packages with it. (For example, I suppose we could wait until GCC 4.5.1 before doing a rebuild.)
I'm not sure we should be too worried. Already over 1/3 of the repo is built with it and only 1 package has been reported broken (and one other not in the repo). Anyway, I will be doing a new gcc rebuild when the next 4.5 snapshot gets released (~24 hours away). That has a fix for at least one of the issues we have encountered. Allan
Hi, The TODO list has been created for this "rebuild". Obviously no rush on this one given it is not a real rebuild. And remember to consider whether the package really needs to stay in [community] given many have not been updated in ages. Cheers, Allan
On 05/22/2010 04:58 PM, Allan McRae wrote:
Hi,
The TODO list has been created for this "rebuild". Obviously no rush on this one given it is not a real rebuild. And remember to consider whether the package really needs to stay in [community] given many have not been updated in ages.
Cheers, Allan
computertemp moved in aur. last version was in 2006. Thanks for doing this. -- Ionut
On 05/22/2010 05:23 PM, Ionut Biru wrote:
On 05/22/2010 04:58 PM, Allan McRae wrote:
Hi,
The TODO list has been created for this "rebuild". Obviously no rush on this one given it is not a real rebuild. And remember to consider whether the package really needs to stay in [community] given many have not been updated in ages.
Cheers, Allan
computertemp moved in aur. last version was in 2006.
Thanks for doing this.
pymsn moved in aur. was replaced long time ago by papyon -- Ionut
Allan McRae wrote:
Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place such as: *SNIP* - package() functions
Hi, Should we always have a package() function? Are there situations in which it is not appropriate? -- Chris
On 23/05/10 00:37, Chris Brannon wrote:
Allan McRae wrote:
Given these packages are obviously not updated much, it would be good to give them a rebuild to get new packaging policies in place such as: *SNIP* - package() functions
Hi, Should we always have a package() function? Are there situations in which it is not appropriate?
package() functions are good as if one is present then fakeroot will not be used during the build() function. However, some packages are all install and no build, so they do not need a separate build() and package() functions. As makepkg-3.3 can not handle PKGBUILDs with a package() function and no build() function, in that case it is best to stick to using just a build() function. (pacman-3.4 will fix that) Allan
participants (9)
-
Allan McRae
-
Caleb Cushing
-
Chris Brannon
-
Evangelos Foutras
-
Ionut Biru
-
Isaac Dupree
-
Ray Rashif
-
Stefan Husmann
-
Xyne