Kind request: fix your packages

[Nicolas Mailhot]

Le sam 04/10/2003 à 05:23, Sean Middleditch a écrit :
> On Fri, 2003-10-03 at 17:43, Nicolas Mailhot wrote:
> > Le ven 03/10/2003 à 22:39, Sean Middleditch a écrit :
> > > On Fri, 2003-10-03 at 16:11, Michael Schwendt wrote:
> > 
> > > > > Perl/Python are co-installable with different versions, and thus are a
> > > > > different issue.
> > > > 
> > > > Oh, great, a second Perl installation. As if Python/Python2 wouldn't
> > > > be enough already.
> > > 
> > > If that's what it takes to make things work, then that's what it takes. 
> > > I didn't say it was perfect, just that it solves the problem that users
> > > shouldn't ever have to rebuild to software, and users shouldn't have to
> > > run around figuring out what their system is to find the right package
> > > and deal with that mess.  In a truly ideal world, Perl/Python/etc.
> > > wouldn't keep breaking compatibility so often.  ~,^  Since that's *not*
> > > reality, the only solution left for sane packages (form a user's point
> > > of view again) is to let any necessary versions be installed so the
> > > user's apps just work and the user doesn't even have to think about OS
> > > versions or dependencies.
> > 
> > Don't make me laugh. The user cares about duplicate stuff too.
> > Before we build a serious infrastructure that enabled us to modularise
> > stuff someone would complain every other week we shipped java 1.3 jars
> > with our tomcat rpm (and those jars were necessary to run it with a 1.3
> > jvm, and didn't hurt when using a 1.4 jvm. But for a 1.4 user they were
> > redundant stuff and we got complains).
> 
> 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.

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.

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

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

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.

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.

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.

Cheers,

-- 
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/20031004/d1a1434e/attachment.sig>