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,