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
