On Mon, Aug 02, 1999 at 05:28:05PM +0200, Santiago Vila wrote: > > What I am objecting to is wording in policy to the effect that we should > > do something, followed by "don't do this for potato". Especially if it > > doesn't really matter if it's done for potato or not. > > So maybe we both agree that a policy which is not to be followed is not > good, after all :-) Exactly. I intend it to be followed by any package uploaded before potato which migrates to the FHS. Packages which do not migrate yet may technically be considered to have several bugs in them, however we have already agreed that these should not be considered real issues for potato. In fact, they should only be considered an issue for potato if the maintainer is going to upload a new package anyway and is sure the FHS transition won't break anything in their package. Otherwise, I think it's safe to say that packages should not change for potato if they're not going to be changed anyway. The policy is meant to be followed, but we can informally agree that it's not required that it be followed until after potato is released. If packages do follow the new policy, great! Otherwise... > > Um, so .... upload a base-files that does this now and let it get > > installed into a few mirrors... If the dselect methods cannot handle > > this, they are broken. apt can handle it and is AFAIK the default with > > potato now that apt has a working cdrom method... > > I didn't say dselect can't handle this. It can, but if you use a dselect > method which does not do package ordering, you will get lots of "errors" > and will need several [I]nstall passes. > > BTW: The same will happen if lots of essential packages in potato > depend on libc 2.1. Do we plan to avoid it this time? No way to avoide it. The essential packages were the ones that broke when we upgraded. It may be easier to fix the dselect methods that don't order packages to be quite honest. That's the correct place to fix the problem. -- Joseph Carter <knghtbrd@debian.org> Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -------------------------------------------------------------------------- <Culus> there is 150 meg in the /tmp dir! DEAR LORD
Attachment:
pgpB2RBssFlCD.pgp
Description: PGP signature