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

Re: Kind request: fix your packages



Le sam 04/10/2003 à 18:23, Sean Middleditch a écrit :
> On Sat, 2003-10-04 at 04:55, Nicolas Mailhot wrote:
> > Le sam 04/10/2003 à 05:23, Sean Middleditch a écrit :
> 
> > > Are you talking about users, or sysadmins/hackers?  I'd doubt a user
> > > would even know a jar file is, or their installed version of Java. 
> > 
> > Well java is a bit special.
> > Most upstream projects do not care about packaging at all (you know, big
> > ugly system-dependent mess, not like their WORA nirvana) so people are
> > used to struggle to install stuff. When they're fed up they find a nice
> > packaging project like jpackage and are delighted ; however they can see
> > if you've done something less optimal that what they did manually before
> > and will complain (loudly) in that case.
> 
> The package could have been split up nicely and with dependencies on
> either a 1.4 jvm or your 1.3 jar file addons, resulting in a small
> download for java 1.4 users and continued ease of use for java 1.3
> users, no?  (assuming you did something along these lines - haven'tu sed
> your packages)

All external deps spun out of the package, 1.4 jvm providing the same
virtuals deps as standalone 1.3 bits, run-time shells scripts that picks
whatever jars are present on the system. The tomcat rpm is now lean and
mean and the jars can be reused by whatever other app (jboss...) can
need them.

The only problem is if one installs a partial 1.4 system and a partial
1.3, and the sum of them provides all the virtuals tomcat needs but
neither the 1.3 nor the 1.4 set of rpms is complete enough to support
tomcat (ie there is no real way to tell rpm that A+B is ok and C+D is ok
too, you have to require X and Y, have A & C provide X and B& D Y -
which breaks on a A+d system). Thanksfully only developers ever try
that.

> > But even if the proportion of clueful users were less for a mainstream
> > project like Fedora I strongly object to the idea bad packaging should
> > be allowed to ease some users pain. If you drive out all enlightened
> > users the contributor pool will dry up and Redhat will be left alone
> > supporting Fedora - not something they're ready to I think.
> 
> I'm not arguing for "bad packaging", i'm arguing for *correct*
> packaging.  One package should always work; its dependencies just need
> to be correct to ensure this.  Putting everything needed in one package
> is not the solution I've asked for at all, if you read this thread, with
> the sole exception of broken dependencies that can't be packaged any
> other way.

Then no one will argue with you here.
I'm sure we'll always find a way not to package stuff in a single
package;)

> > > Certainly, every user I've dealt with recently (including a handful
> > > friends and a number of coworkers) would have no clue; they can barely
> > > remember their OS is "Microsoft Windows" and not "Compaq Explorer." 
> > > ;-)  (and no, that isn't an implication users are stupid, merely that
> > > they often don't know much about computers.  i can't keep the names of
> > > various parts of a car engine straight, but that's only because i'm not
> > > really familiar with it, and I don't really care in the least, so long
> > > as it moves.  just like many users don't care how the computer runs,
> > > jsut that it works.  and yes, that was a real example, not my usual
> > > satirical exaggeration ;-)
> > 
> > Sure. But do you see any of them installing Fedora by themselves ? If
> > there is someone clueful enough somewhere to install Linux he will
> > understand some packaging issues so your example is not relevant (and he
> > won't have to understand everything to point out at least a few
> > mistakes)
> 
> 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.

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.

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

[...]

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

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

[...]

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

Regards,

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=


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