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

Re: Slink to Potato

On Sun, Oct 03, 1999 at 10:02:55PM -0400, Damir J. Naden wrote:
> Hi Mark Brown; unless Mutt is confused, you wrote:

> > That idea is intented to be closer to unstable than stable - at this
> > point, there would probably be as much hassle updating to the in-between
> > release as there is updating to Potato.  Not that there's much hassle
> > with Potato right now.

> if I feel bored over the weekend; what packages and in which order do I
> need to update to get the system to potato- with dpkg command line _not_
> the apt tool? I'd guess libc6 2.1, bash, ldso, libreadline2g and so on
> and so forth. (any volunteeres for a quick how-to? :-) )

That sounds like the sort of thing that a machine is much better at than
me.  The quickest way to generate such a list would probably be to do an
apt --dry-run.  :-)

> Now, I want new wmaker (assuming there is a package): I do dpkg --i
> wmaker* and two or three other small packages, and I'm off to the races.
> Since it is a bug-fix release, I don't think anything will break. If it
> does, I pull out old packages, do dpkg --i thingy, and I'm safe. An hour
> work, at the very worst.

What happens if a package really does depend on a new library version, 
or the package maintainer did a lot of work adding support for some
infrastructure which is only in unstable?  At what point would you be
happy with something that depended upon something that wasn't in stable?

> > The stable GNOME packages are actually produced by the Debian
> > maintainers - they're just distributed from the GNOME site.

> So, why would they not be introduced into slink-proposed-updates?

The only things in proposed-updates should be minimal fixes for very 
important (eg, security) bugs - things that will go into a new point
release of slink.  New upstream releases don't generally make those 
criteria, and the GNOME one certainly doesn't.

> > To explain it a bit more clearly: glibc 2.0 is binary compatible with
> > glibc 2.1.  If programs break when linked against 2.1 then that is a bug
> > in the program (typically trying to use internal features).

> With all due respect, from my standpoint it doesn't matter where the bug
> is. The fact the program may not run does matter.

It at least tells you where to file the bug report.

Mark Brown  mailto:broonie@tardis.ed.ac.uk   (Trying to avoid grumpiness)
EUFS        http://www.eusa.ed.ac.uk/societies/filmsoc/

Attachment: pgpO3DYT1HpPQ.pgp
Description: PGP signature

Reply to: