Previously Joseph Carter wrote: > My first condition is that this is phased in--it must not be a requirement > for potato or even potato+1. (I'll accept potato alone if a reasonable > consensus of people believe we can do it for potato+1 without interfering > with release timeframes..) I'm looking into how much work it is, from what I see so far it's actually not that much work. > My second condition is that this is done as part of the ftp archive revamp > rather than before or after. If Guy is going to implement pools for > potato+1 it doesn't make sense to make a bunch of changes that include > significant modifications to dselect twice. Please let me worry about dselect. This should be implemented at the end of this week, thanks to GNU who is putting one of their staff hackers on this. > ie, if packages are going to start using Enhances, they should start > using Keywords at the same time. This (hopefully) prevents duplicated > work and wasted bandwidth. I'm thinking of adding a limit-command to dselect like mutt has. It seems pretty doable I'm not promising anything soon. > I realize both of these are implementation issues, however the /usr/doc > fiasco has shown that anything not documenting current practice that isn't > backwards-compatible needs implementation issues discussed beforehand. The /usr/doc issue was a) blown all out of proportion and b) affected all packages. Comparing that to this doesn't make much sense. You seem to think that this needs a change in the archive and mention it being related to that a couple of times. Please realize that is not true at all. It means a few changes to a handful of packages and some coding work on dpkg and dselect. Wichert. -- ________________________________________________________________ / Generally uninteresting signature - ignore at your convenience \ | wichert@liacs.nl http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Attachment:
pgpUv5EG7fCoz.pgp
Description: PGP signature