Re: [PROPOSED] Change package relations policy to remove references to non-free from main
On Sun, Nov 28, 1999 at 10:14:29PM -0800, Joseph Carter wrote:
> I will conditionally support this...
>
> 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 agree that we shouldn't require it for potato. I agree that non-compliance
with this policy probably won't be release critical. On the other hand,
I find it hard to imagine any circumstance that would prevent fixing
the small set of packages which would be affected by this policy by
potato+1.
> 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. 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 think what you're saying here is: the policy which supports Enhances:
should be the same as the policy which supports Keywords:
?
[Because it would be silly, in this case, to postpone package updates
till after some proposed ftp site administration gets done.]
> The reasonable condition that bandwidth not be wasted by modifying every
> (or at least most) packages twice I think is just a practicality concern.
> It's also a convenient excuse to make sure this is done at the same time
> package pools are so moving of non-free and contrib to help seperate them
> from main can happen at the same time.. Hopefully this will make sure
> people trying to do all of those things cooperate and things happen
> smoothly.
Sure, but this concern applies to most policy updates, not just the two
you mentioned. More generally, we need some kind of release management
for debian-policy and that should somehow interelate to general debian
release management.
This a rather larger topic, in general, but hopefully we can just rely
on the policy editors for now.
--
Raul
Reply to: