Kind request: fix your packages

[Sean Middleditch]

On Sun, 2003-10-05 at 04:23, Nicolas Mailhot wrote:
> Le dim 05/10/2003 à 08:08, Sean Middleditch a écrit :

> > I still have absolutely no clue what you are talking about.  I haven't
> > once at all argued any specific dependencies must be embedded.  I said
> > that *if* a dependency is so broken it can't be sanely coinstalled, at
> > all, then it needs to be embedded, versus the current practice of only
> > letting the user have one version installed at a time (and thus forcing
> > them to use either package set A or B).  That's it.  That's all I said,
> > ever, about the embedding topic.  You're going on and on about something
> > nobody's even arguing against you about.  *applause*
> 
> But what you argue for is already current practice (see how the xft port
> of mozilla was done). And it should be limited, not extended because it
> has real costs for the end-user.

I'm not even sure you know what I'm arguing for.  Why are you going on
and on about code duplication when that was one teensy little minor
point I made just for *very* rare cases where there is *no* other
solution?  Seriously, *what* are you going on about that I'm disagreeing
with?

> 
> > > I'm sure someone on the list will always find a way to avoid embedding s
> > > 
> > > > > releases. Sacrificing the system sanity to the golden cow of eternal
> > > > > upgradeability however will only produce a Windows-like mess were
> > > > > everything "sort-of" works for everyone. You have to do some spring
> > > > > cleanups, even in real life.
> > > > 
> > > > This, of course, is the purpose of deprecation.  We have GNOME2 and
> > > > GNOME1 libs in RH9, but as soon as all apps move off of GNOME1/GTK1,
> > > > those can be removed.  Apps that, 5 years later, still rely on 5 year
> > > > old incompatible libraries, probably need to be removed or replaced.  Or
> > > > at least patched to work on new systems, if they're somehow
> > > > super-mandatory.  (which would be an ugly situation)
> > > 
> > > Just freeze the repository at release time and have all new packages go
> > > into an unstable branch (or at least require them to go into unstable
> > > before hitting stable). If something didn't get packaged in unstable by
> > > the time it's time for another release - drop it.
> > > 
> > > The announced release frequency is high enough people can wait for the
> > > next release for new stuff.
> > 
> > This is about as dumb as it can get.  I have to upgrade an entire
> > fricken OS for maybe one piece of software I want?  *bzzt*  Let's try to
> > move forward, not backward, here.
> 
> Really, I don't see why you oppose a clean upgrade every few months when
> your solution would result in massive code duplication. In my scenario
> at least the on-disk system size wouldn't grow exponentially over time.

Because when people want software, they want it *now*.  If you tell
them, "well, you have to wait two months to install that software, even
tho the software it already out now" then they're going to (rightly)
switch to an OS that doesn't suffer from a complete lack of backward or
forward compatibility.

And, again, the above has *ABSOLUTELY* nothing to do with with embedded
dependencies.  Just good packaging habits.  Disk size only grows if the
user *needs* multiple versions of something.  Good packaging would
*avoid* that as much as possible.

Take a look at Debian - they quite often a have a couple versions of
certain components *available*, altho they usually aren't ever
*installed*.  If the user needed, say, and older version of Python for a
piece of software, it's usually there for them.  But, most of the time,
the user doesn't actually need it.

So long as the dependency is available, then both older and newer
software can be installed.  The dependencies are *only* needed when app
*actually* uses them. And even if you install version 1.2 of an app that
needs dependency foo 1.0, you're still completely allowed to make a
release of the app 1.2-1 that uses the more up-to-date foo 1.02.  Users
aren't forced to update their app, but those that do don't have to deal
with the "legacy" dependency.  Users of an OS release that only had foo
1.0, upon install of the new 1.2-1 version of the app, would have foo
1.02 pulled in as the dependency.

> 
> Regards,
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.