[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Kind request: fix your packages
- From: Sean Middleditch <elanthis awesomeplay com>
- To: fedora-devel-list redhat com
- Subject: Re: Kind request: fix your packages
- Date: Sat, 04 Oct 2003 12:23:23 -0400
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
> 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
> > 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
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.
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...)
> > > Show me a repository with big fat packages that include all deps to be
> > > standalone and I'll show you a repository no one wants to use. Users may
> > > not all know the zen of packaging but it will only take a few long
> > > downloads or stuffed disks to enlighten them.
> > All dependencies embedded aren't at all needed. Just the ones people
> > can't develop and/or package correctly.
> I like the "just" bit.
> That was already the case for libgal for a long time. And it is a pita
> for normal users - package managers like apt do not like duplicate stuff
> so people have to largely handle this manually.
Libgal wasn't really a "public" library, either. Apps depending on a
library like that need to realize what that means.
> Don't open the gates if you're not prepared to handle the flood that
> *will* follow.
> > If things were developed using
> > sane release and maintenance practices, you'd never have need to ship a
> > dependency with an application. It's only when the dependency is
> > released/maintained in the usual inexperienced 13-year-old style that
> > you need to do that. ~,^
> 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?
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.
There will *always* be upstream sources from hell, but a solid packaging
policy and avoidance of the cheap route out should let packagers deal
with them in a sane manner. If not, then they will at least be the
*exception*, and not the *rule*.
I never claimed things will be 100% perfect, just that the majority of
packages should work sanely. ~,^
> Someone must say stop at one point. It might be a larger project
> (Gnome), a packaging project (Fedora) or the end-user (because in the
> end duplicating stuff is a maintenance burden and you're only exchanging
> upstream-level work with packager or user work by embedding stuff).
> You're right most users do not want to bother with package deps. You're
> wrong however in thinking they'll accept the mess a massive embedding
> policy would foster on them.
Again, *only* when embedding is the *only* choice. I don't like
embedding any more than you, but when it's either embed or force the
user to upgrade the entire system for one app...
Your other mail indicates you seem not to be following that. Embedding
isn't the answer, it's the hack needed when upstream breaks things for
us. The answer isn't always the extreme; there *are* shades of gray.
;-) (just hopefully mostly towards the bright side)
I'd imagine in almost all cases the embedding can be gone without. If
nothing else, putting libraries/packages like that in different
locations would help. A policy would be needed so people could know how
to do that tho, and not end up with a bunhc of random, incompatible
> I'm perfectly happy with un-packageable projects (ie projects that do
> not address packager needs and can not work with the same deps as the
> rest of the system) being kicked out of Fedora. I'm also perfectly happy
> with old releases not getting the same kind of care as new ones. They
> have to die at some point - you can not support every single release at
> vitam eternam. Nobody here will knowingly make upgrades harder for older
> 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)
You only need the legacy cruft installed if you are using a legacy app.
Windows' mess is due to the fact that it can't grab legacy cruft on app
install, so it always has to have it laying there. Fedora can always
ship its core CD(CDs if we continue with the "stuff too much crap in the
base OS" philosophy) with only the cutting-edge stuff, and put legacy
support packages on the other CDs or online for fetching w/ up2date.
(It would also be nice if the system could detect when a "support"
package, like a library, is no longer used and can be removed - tho that
would need to be easily overridable for those of us installing thigns
from source ;-)
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.
[Date Prev][Date Next] [Thread Prev][Thread Next]