[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: List of bugs that *must* be fixed before freezing Hamm



On Sat, 14 Feb 1998, Santiago Vila wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> On Sat, 14 Feb 1998, Dale Scheetz wrote:
> 
> > On Fri, 13 Feb 1998, Santiago Vila wrote:
> > 
> > > How will you add a Conflicts line to the old emacs?
> > > It's stable and it may not be changed.
> > 
> > What would be the point?
> 
> The point is avoiding the user to install libc6 *without*
> upgrading emacs also.

But traveling back in time and making emacs conflict with the future libc6
would not resolve the problem. In any case I haven't figured out how to
travel backwards in time yet (I'm doing well to stay with the present),
thus the question seems to have no point.

> 
> If adding a "Conflicts:" header is not the right thing to do, then someone
> please write a little document called "Release notes for Debian 2.0" 
> containing the full list of packages that will stop working if you install
> *just* libc6. Would this be ok?
> 
This release is definitely going to need a complete set of upgrade
"release" notes. It was my understanding that the libc5 to libc6 howto was
the current "working document" in that reguard.

Should this class of upgrade hassle be detailed in that document, or is it
time for someone to maintain a "true" release document? I don't know where
I would find the time for such a task, but consider me "option of last
resort".

Another way to approach this problem would be to get a "fixed" version of
emacs into bo, so there is an appropriate upgrade path to take "before"
upgrading to hamm. The added complication with this package is that the
new hamm package is no longer named emacs, but is now emacs19. This
further clouds the path from the users point of view.

For the same reasons that "getting to release" for this library transition
has been longer than a "normal" cycle, upgrading from libc5 to libc6 is
not going to be as easy as previous upgrades have been. autoup.sh is where
most of this complexity is being dealt with at the moment. The name change
of timezone to timezones [1] may be dealt with by this script, so
possibly this is the correct place to deal with the problem?

[1]: This package's name transition was complicated by a "broken" rex
version that had itself declared "essential", while the bo and hamm
version were not (with the name change happening between bo and hamm).

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"    _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: