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

Re: etch-m68k security update



On Mon, Jun 25, 2007 at 06:08:06PM +0100, Wouter Verhelst wrote:
> On Sat, Jun 23, 2007 at 10:40:11PM +0000, Bill Allombert wrote:
> > On Sun, Jun 24, 2007 at 12:08:32AM +0200, Luk Claes wrote:
> > > If you mean for etch, I guess you should upload them to etch-m68k.
> > 
> > I will not do that: I do binary-only upload so etch-m68k Sources file
> > would not match the Packages file. Also I want to make etch-m68k identical
> > to etch, so etch-m68k Sources file should stay identical to etch Sources
> > file.
> 
> Just FTR, that's not the way it's implemented. Since we can't get
> updates to etch anymore, etch-m68k is supposed to be a different suite,
> which generates its own Sources file. You can /try/ to make them
> identical, but if updates are needed, then that won't happen (because
> then you really do need updates).

I am unsure I understand why sourceful updates would be needed:

1) Currently etch-m68k Source file is identical to etch Source file, even
though some binary packages are not up-to-date (so they do not match the
source packages), and I cannot update these binary packages because I
get REJECT.

2) Etch _will_ be updated: for 4.0r1, 4.0r2, etc. We can certainly ask
for etch-m68k Source file to be updated in the exact same way, providing
we build the binary packages (which I have done for 4.0r1). 

3) Remains the option to fix bugs by uploading new source packages with
changes that will not get past the stable release. As far as I am
concerned I don't know about any bugs in the current etch-m68k that
would warrant that or serious efforts in that direction. If you go in
that direction, I feel no right to object, but that would kill any
attempt for inclusion in Etch.
 
Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Reply to: