Kind request: fix your packages

[Sean Middleditch]

On Sat, 2003-10-04 at 13:15, Nicolas Mailhot wrote:
> Le sam 04/10/2003 à 18:23, Sean Middleditch a écrit :

> > This is complete nonsense.  I've two friends just the last couple weeks
> > that have RH9, one I installed for him (since I helped build his
> > machine) and the other installed by the friend after I gave him CDs. 
> > Neither of them understand jack about the packaging, and I've already
> > had to make tons of excusses for the insanity of it (along with other
> > Linux stupidities, which are another topic entirely).  Getting calls at
> > 10pm because they can't figure out how to get OpenRPG installed (or
> > whatever) is irritating.
> 
> So would have standalone apps changed anything ? No. They'd have called
> you because your integrated app used its own config files and didn't
> pick up the system settings they chose in the control panel.

No offense, but... where the hell are you getting this stuff from?  I
haven't said *anythign* about system settings, and even if I did,
"integrated" rather means it *would* use them.

> 
> What could have changed something is the app be properly packaged in
> Fedora (for example) and your friends being taught to use
> apt/yum/whatever.

I doubt Fedora is ever going to package all useful software, and users
shouldn't need to learn to open up a command line and type cryptic names
of software when they are on the software's website with a fricken link
to it right there.

What should happen is they click on the osftware, *that* package is
installed, and apt/yum is used for dependency resolution (without the
user needing to type or see cryptic things like
libfoo2-common-1:4.5.i386.rpm and so on.)

> 
> > Nobody should *have* to explain it to them, it should just work the way
> > they'd expect - which is click on the package, and watch it install
> > (possibly grabbing dependencies, or providing a very sane/clear message
> > if they cannot be found, which is another RPM problem...)
> 
> ROTFL.
> The way they expect it is you doing the install for them.
> I have questions about MS office every other week even though I'm the
> only person at work who *never* use it 'cos I has a linux desktop (I
> have questions about office by people who use it all the day !). The

I see no correlation between either of those statements... the user
expects not to need to ask anyone about it, since it should just work
they way they expect, not have cryptic/unobvious behaviour.

> problem is not following "what the user expects". The problem is having
> a working framework so people won't assume they should not bother
> learning it because it's as broken as the other ones and asking their
> resident guru is easier anyway.

Right.  A working framework is needed, not just a mass of packages that
are recompiled everytime someone sneezes so they keep working on the
exact snapshot version of some various random Linux OS.

Fix the system so its not broken, and users won't have learn much (why
the hell should they need to care about apt/yum/rpm at all?) *and* it'll
work like they expect

> 
> [...]
> 
> > > I see you've never tried to package a large pool of inter-dependant
> > > projects. In 80%+ of the cases the problem lies upstream. If the
> > > packager accepts the deps upstream wants to force on him the mess will
> > > only grow. Most of the upstream projects I work with would jump to the
> > > possibility to embed all the deps they need because that matches their
> > > vision of their app as the center of the system.
> > 
> > Does anyone bring up these problems with the upstream in these cases, or
> > just work around it?
> 
> Both.
> Strangely enough users understand readily enough what they win in a
> nicely modular system, while upstream developers more often than not
> strongly object to someone even suggesting they massive bundle of
> straight-from-cvs binaries is not proper packaging.

Totally lost by that last sentence, sorry.

> 
> > I might also note that this is most important for user apps, not so much
> > backend/server stuff; my friend Dan (very bright, but never had a
> > computer until last week) isn't going to be installing Apache or a
> > telephony system.  ;-)  A lot of backend apps half the time aren't ever
> > *intended* to be packaged.
> 
> A sysadmin likes its stuff properly packaged like anyone else.

Yes, but sysadmins are expected to understand the differences between
apache, libapache-modssl, libapr, and evolution.  Users, on the
otherhand, would know about Evolution, and probably would care at all
about Apache.

> 
> [...]
> 
> > I'd imagine in almost all cases the embedding can be gone without.
> 
> Then why bring it up now ?
> When you find an app that you feel absolutely needs embedding then it
> will be time to argue. Doing it now over an hypothetical case is
> pointless.

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*

> 
> 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.

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