This one time, at band camp, Goswin von Brederlow said: > Stephen Gran <[EMAIL PROTECTED]> writes: > > > This is a naive patch for the problem - it probably should be subroutine > > refence that handles the require and readability checks and so forth, > > and dies with a sensible error on problems. But this is a first step. > > This is actualy no where near the problem. > > Debmirror already has a config file to set options instead of using > the commandline as either /etc/debmirror.conf or > $HOME/.debmirror.conf. Your patch only adds more freedom to the > filename.
Ah, I completely misunderstood what was at issue in this bug. Sorry. I
was fighting with wanting a config file option since I wanted a couple
of runs of demirror (to grab amd64, but only for sid, as opposed to the
other architectures where I want sid and sarge).
> But the actual problem for this bug is that one might need more
> control what architecture, suite, sections, .... combinations are
> used. For example only fetch amd64 packages for etch/sid since sarge
> has no amd64.
>
> So far the only idea I have to solve this is to have the user list
> every and all combinations wanted manualy like
>
> sarge main i386
> sarge main source
> etch main amd64
> etch main i386
> etch main source
>
> That I find quite tideous and ugly so I'm still looking for something
> better.
I can imagine a syntax like
-S i386,powerpc,arm sarge,etch,sid -S amd64 etch,sid
That would produce something like
%packages = (
amd64 => [ etch,
sid ]
i386 => [ sarge,
etch,
sid ]
powerpc => [ sarge,
etch,
sid ]
...
)
as a data structure, which could then be used to construct the packages
lists and so forth. It's still tedious, but it seems flexible, and not
as tedious as having to do them all individually. The order above
(keying on arch instead of dist) is entirely arbitrary for the point of
the example - it may make sense to key on dist instead, but I haven't
given it that much thought. Making -S a pointer to a subroutine that
built the data structure instead of just setting a variable would be my
way of implementing it.
In order to keep backwards compatibility with other command line
options, I suppose you would then have to build the same data structure
from the other command line options, but that's not too hard to do.
It's more the porting the rest of the script to using the new data
strucure that would get tedious.
If this sounds reasonable to you, let me know, and I'll give it a whack
when I have some time.
Take care,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : [EMAIL PROTECTED] |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
signature.asc
Description: Digital signature
