Am 04.02.2010 13:23, schrieb Allan McRae:
There has been talk about what is needed/wanted for the future of devtools and db-scripts but not much done lately. So I thought I would get together a list of ideas so we could perhaps do a coding sprint to implement them. Here is what I have got so far:
Someone has to do it. I probably don't have enough free time, so I could claim I would do it, but it still wouldn't happen - therefore I will be honest to myself and simply say I won't do it.
devtools - split-PKGBUILDs with (supported in future pacman): -> both binary and arch=any packages -> overridden pkgver -> overridden pkgrel (and only selected sub-packages)
-> Split packages in different repositories (only if they reside in the same SVN tree). This would help dbus and dbus-core, maybe more, like some of the gcc stuff.
- support for xz compression (nothing needed?)
I would make it more general and say support for different compressions. The dev/db scripts shouldn't care what the compression is and simply add any (supported) package, be it gz, bz2 or xz. While we should probably agree on one compression type for everyone, I think our scripts should also support everything without problems. And if there is ever a new compression, we simply add the file extension to the "supported compressions" list in devtools/dbscripts and need no further changes.
db-scripts - support for xz compression transition (e.g. in clean-up script)
See as above, the scripts should be entirely flexible here.
- support for single "package" directory with symlinks to repos
This should be one directory per SVN tree (pool-packages and pool-community), so core/extra/testing and community/community-testing will be separate - otherwise, the whole rsyncing stuff will be a huge nightmare. Also: -> Allow a smooth transition such that the cleanup script handles a mix of "single directory" and the old style gracefully - we don't want to move all packages at once, but only have this single directory for newly added packages.
- allow db-move to handle multiple packages (or add a script to help moving from community-testing)
We should kill these testing2whatever scripts and unify it completely in db-move (including the testing2x case where the right repository is automatically determined). Short-term it would probably suffice to create community-testing2community.
- delta support...
Personally, I would consider that low priority.