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

[Dan McGee]

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.

-Dan