Re: Is the dependency rule distribution-wise?

[Brian White <bcwhite@pobox.com>]

> > 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
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
                  Do, or do not.  There is no "try".  -- Yoda