> > A priority change is not changing "too much", it does not require to
> > compile any package, and it does not make the package to be in another
> > section (i.e. another directory), so not even automatic upgrade scripts
> > would be confused about it.
>
> I agree with you. (Wow, you should mark this red in your calender). I'm
> interested in what Brian thinks about this. If he says go ahead it'll be
> fixed soon, if not, it'll be fixed in potato only. I can understand this
> although I would like to have slink be fixed as well.
As long as the packages don't have to be changed, it's okay with me.
> > In either case: do we agree that once we have decided not to recompile the
> > packages, this is a bug in the override file for slink, because priorities
> > are release-wise?
>
> It is a bug in slink if so, yes. At least I agree, but I also acknowledge
> that slink is in deep freeze and that this could be a reason against changing
> priorities. For me, it's up to Brian to decide.
Since priorities are for the most part just a convienence, it doesn't make
much difference. Is I understand it, priorities are only used for grouping
packages when displayed by dselect and by CD makers for grouping packages
on to CDs when more than 1 must be pressed.
Thus, if you can do it just by causing the "Packages" file to be generated
with the new priorities (which I believe you can), then it's okay by me.
And, since it's easy to test just by doing a diff between the old and
new "Packages" files, the chance of error is small.
But, this has to be done _immediately_ or not at all.
Brian
( [EMAIL PROTECTED] )
-------------------------------------------------------------------------------
Do, or do not. There is no "try". -- Yoda
