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

Re: debram and packages temporarily absent from sarge



On Tue, Apr 05, 2005 at 05:06:11AM -0700, Steve Langasek wrote:
> Hi Thaddeus,
> 
> On Mon, Apr 04, 2005 at 07:48:16PM +0000, Thaddeus H. Black wrote:
> > This mail is somewhat lengthy, and most of you do not
> > need to read it.  You want to read this mail if you
> > maintain packages which (as of 2 April) sarge
> > temporarily lacks.  These are packages which used to be
> > in sarge and still have hope to join the official sarge
> > release but, for whatever reason (probably RC bugs), are
> > not in sarge at the moment.  If you do not have this
> > problem, you can safely skip this mail.
> 
> > On Thursday night, I intend to update debram-data for
> > the last time before the freeze, purging metadata on all
> > binaries not in sarge main (i386) 2 April.
> 
> I'm puzzled as to what the rationale would be here.  Is the package so large
> that you need to trim metadata for packages that aren't currently in
> testing?

No, it isn't.

> Wouldn't you want the debram shipping with sarge to be maximally
> useful with packages in etch/sid?

Hm.  Perhaps so.  For historical reasons peculiar to debram, the matter
had not occurred in quite this light.

Now that you mention it, I can think of no substantial objection to your
suggestion.  Because of the kind of thing debram is, one is loath to
disregard a Release Manager's advice in the matter---but even were it
not so, your idea still has merit.

Purging is fast and easy, so I can implement your suggestion easily in
either of two ways:

  (1) to leave debram-data as it is, purging nothing; or
  (2) to purge metadata for packages not presently in sid.

These options contrast against my earlier plan:

  (3) to purge metadata for packages not presently in sarge.

Now, some sarge stable users might prefer debram to list only packages
actually available in sarge stable.  The debram(1) executable does not
differentiate, and there is no time to make it differentiate now.  Any
metadata we decide not to purge, the user is going to see on his screen.

However, I have already (option 3) purged all the obsolete woody
packages less than a year ago, so it is not as though debram-data were
drowning in cruft today.  About 94 percent of debram-data treats
packages now in sarge; only 6 percent of the data is in question here.
Debram is not an exact science.  I think that the sarge stable users
will be okay in any case.

Would you advise option (1) or option (2)?  (Or even option 3?)  The
same question goes to the Debtags team and other stakeholders.  Sans
further feedback, I guess that debram would now take option (2)---but
all the options seem acceptable: we can go any way with this.

(Technical note:  I said above that the debram(1) executable does not
differentiate between sarge and etch/sid packages.  Actually, with the
--selections and --data-file options, the sufficiently determined user
can make debram(1) differentiate arbitrarily.  However, this is too much
work for casual debram use.  What debram lacks is a convenient --sarge
switch.  This is what I meant.)

Attachment: pgp1aREvNtxrn.pgp
Description: PGP signature


Reply to: