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

Dan McGee dpmcgee at gmail.com
Sat Feb 6 16:04:36 EST 2010

On Fri, Feb 5, 2010 at 9:35 PM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
> On Thu, Feb 4, 2010 at 12:26 PM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
>> On Thu, Feb 4, 2010 at 7:23 AM, Allan McRae <allan at archlinux.org> wrote:
>>> Hi all,
>>> 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:
>>> devtools
>>>  - split-PKGBUILDs with (supported in future pacman):
>>>   -> both binary and arch=any packages
>>>   -> overridden pkgver
>>>   -> overridden pkgrel (and only selected sub-packages)
>>>  - support for xz compression (nothing needed?)
>>> db-scripts
>>>  - support for xz compression transition (e.g. in clean-up script)
>>>  - support for single "package" directory with symlinks to repos
>>>  - allow db-move to handle multiple packages
>>>   (or add a script to help moving from community-testing)
>> There are already testing2community* scripts in git as well as a
>> db-community-testing. They just need to be released on sigurd.
>>>  - delta support...
>>> Any others?
>> Couple of bugs that could be fixed.
>> FS#17058 - {dbscripts} ftpdir-cleanup marked new packages as out of date
>> FS#17098 - sourceballs: Removal of old sourceball not efficient
>> Probably sourceballs and sourceballs-cleanup should be merged.
> I made a patch for that. It's untested yet.  As I can't test it on my
> system, I'll need to test it on gerolde. I could make my copy of the
> sourceballs directory in my home directory.  It'll be the most
> convenient for me if fixes needs to be done but it'll use up
> (temporarily) 9.5-10 GB of the avaliable 11GB of disk space.
> Alternatively, an admin could start the new scripts while I'm able to
> keep an eye on it and stay available in case the script needs to be
> stopped. I could also just send a git patch of the untested script.
> Any idea on the best way to proceed?

Don't copy, use hardlinks or symlinks please.


More information about the arch-dev-public mailing list