[arch-dev-public] devtools and db-scripts plans

Thomas Bächler thomas at archlinux.org
Thu Feb 4 07:49:26 EST 2010


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20100204/ad5c8856/attachment.bin>


More information about the arch-dev-public mailing list