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