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:
pgpgGnifxELEM.pgp
Description: PGP signature