[arch-dev-public] dbscripts pkg pools
Aaron Griffin
aaronmgriffin at gmail.com
Mon May 3 18:19:07 CEST 2010
On Mon, May 3, 2010 at 5:59 AM, Pierre Schmitz <pierre at archlinux.de> wrote:
> On Sun, 02 May 2010 18:10:40 +0200, Pierre Schmitz <pierre at archlinux.de>
> wrote:
>> What about a directory structure like this? We could also remove the os
>> subdir and backwards compatibility could be achieved by some symlinks.
>>
>> ftp
>> └── repo
>> ├── arch
>> │ ├── core
>> │ ├── extra
>> │ ├── packages
>> │ └── testing
>> └── community
>> ├── community
>> ├── community-testing
>> └── packages
>>
>> The actual names might not be final, but with this structure we separate
>> our repos from everything else on the ftp and we separate the "official"
>> and community repos from each other.
>
> Here is a proposal which is more backwards-compatible and doesn't need a
> complete resync; just a few modificatinos to the db-scripts. (e.g. we need
> to define which repos the cleanup-script should check)
>
> ftp
> ├── core
> ├── extra
> ├── testing
> ├── community
> ├── community-testing
> └── packages
> ├── arch
> │ ├── i686
> │ ├── x86_64
> │ └── any
> └── community
> ├── i686
> ├── x86_64
> └── any
>
> The top dir repo dirs are kept. They include symlinks to the packages in
> the packages dir. Packages from community are kept separate. We now just
> need to modify the db-scripts and define the repository names it should
> work on. (especialy the cleanup-script should only search in core,extra and
> testing but not community for example.
>
> The community, community-testing and packages/community dirs would still
> be rsynced from sigurd.
>
> What do you think about this layout? It wont need any chagne on the
> clients (mirrorlists still work) and no resyncs are needed.
In the spirit of this, I broke out the "packages" dir to a variable so
that we can change it:
http://code.phraktured.net/cgit.cgi/dbscripts/commit/?h=pkgpools&id=ee4074de910df5c637691ace06ec5a9d475fb4a3
On gerolde, it'd be packages/arch and on sigurd, packages/community (in theory)
More information about the arch-dev-public
mailing list