[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: