Re: [PATCH] Support multiple components and non-i386 mirrors in which_deb
[ cc: to you as I don't know if you're on the mailing list ]
Hi Jonathan,
On Fri, Jan 23, 2009 at 12:14:14PM -0600, Jonathan Hall wrote:
> I'm working on building some custom CDs, which contain a subset of the
> 'main', as well as our own component, 'local'. Limitations in which_deb
> prevent debian-cd from finding our version of debootstrap, in the
> 'local' component, as it only looks in main. This patch adds support
> for a 5th (through nth) argument, to specify which components to look
> in; without this option specified, it looks for all
> $component/binary-$arch/Packages.gz files, to build a list of components
> to search.
>
> It's unclear to me whether the optional arguments will ever be useful; I
> added this in case it was ever important to explicitly exclude contrib,
> non-free, etc, from these searches. If this is not useful, then it will
> be simpler to build the @components array dynamically on every
> invocation.
OK, I'm happy with that change. Looks OK, and is an obvious extension
to allow more flexibility when people replace packages in main.
> Additionally, we will likely be completely dropping i386 support for our
> own custom distribution soon, so I have also modified which_deb to look
> for i386 *or* amd64 as a $default_arch to be used in place of 'i386'
> throughout the script.
To be honest, I'd be happier to see that implemented as a fallback
done later: call grab_bin_info() for i386, then amd64 if that fails? A
global "default" arch seems a little awkward to me, as we may end up
searching more arches for some of the other packages too.
> Perhaps I should have done these two changes as two separate diffs, but
> at this point I suppose feedback on these two changes is more useful
> than anything anyway. In particular, whether the 5th argument is
> something that's important to support.
>
> The multiple-component bit applies to bug #489516, although to
> completely close that bug, additional changes will be necessary as
> well--which I would be happy to also work on, so that we aren't forced
> to use 'local' as our custom component name :)
Sure. :-) More patches welcome for that, although all these changes
are looking to be a little late for lenny now.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"
Reply to: