Kind request: fix your packages

Sun Oct 5 08:23:51 UTC 2003

Le dim 05/10/2003 à 08:08, Sean Middleditch a écrit :
> 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.

I'm taking this from the last integrated solutions we've got : mozilla
with its own xft stack, jvms we have to package and so on.

The fact is when you start defending against system libraries conflicts
by shipping your own "tested working" private versions you also ship
your own versions of the configuration files they use because even
though you might be able to read the system versions of those files at
first you know there's a big risk once the system updates its own
backend their format may change and your private libraries will no
longer grok them.

In my experience the kind of defensive packaging where all deps are
bundled with the app always leads to configuration files duplication for
this reason, with the direct result of the user having to do the same
operation twice or more on the system because the standalone components
won't talk to each other ot to the system.

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

They won't have to. Unlike old RedHat this is a community project now
and people can submit packages here that work with the same repository
instead of the semi-working stuff projects used to propose alongside
their tar downloads.

It only needs to reach critical mass so enough stuff is packaged users
can ignore unpackaged stuff (or shame upstream projects into packaging
their own mess).

At this point I doubt many useful software will be left packageless.

>  and users
> shouldn't need to learn to open up a command line 

There are beautiful clickey frontends you know.

> and type cryptic names
> of software when they are on the software's website with a fricken link
> to it right there.

Co's they didn't have to type cryptic names in their navigation bar to
get thier software right ? And the fricken link system you find on sites
like sf (to name it) are not fricken more annoying than an apt system
that does everything in the background ?

The answer to your problem is something like the profile I've discussed
with Havoc, not some sort of standalone monstruosity (which will
inevitably be installed userside and not be shared among the system
users since unix rights are something else you won't want to teach your
ex-ms users)

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

And here we agree at last. But take it any further and you'll see there
no need to have them download the core package at all either since it
can be apted like the rest.

[...]

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

Here you introduce your own technical bias again.
The user won't care if its rebuild every hour at long at it works.

> 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?)

Why the hell should they need to care about your installshield-like
setup ? It's not even as if it were working as well as apt/yum/rpm.

[...]

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

Ie most of the times upstream are outraged we do not want to use the
binary bundle they've assembled from their own code and binary
dependencies they lovingly extracted from their own cvs. It works for
them why should it not work for us ? Don't we trust the binaries they
put into their cvs after applying who knows how many hastily hacked
patches, changing the file names so they're sure no one will know where
to download the dependencies original sources ? (short answer - we
don't). Don't we know that if they use two-year old versions of those
very same binaries that's because we should ? (not because they lacked
the manpower to follow the projects they depend on)

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

Sysadmins can be asked to put systems on line in at a very short notice.
They'd rather spend what little time they have to tune the system than
following a ten-ages long manual procedure (which doesn't help much at
crash-time anyway)

> > 
> > [...]
> > 
> > > 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*

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

Regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031005/1b4d6970/attachment.sig>