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.
signature.asc
Description: OpenPGP digital signature
