sane dependencies -- a positive look at 'fix your packages'
Sean Middleditch
elanthis at awesomeplay.com
Mon Oct 13 17:12:32 UTC 2003
On Mon, 2003-10-13 at 12:01, Nicolas Mailhot wrote:
<snip tons of yammering>
> The nice RH people have proved over time you can package anything in
> rpms - from web server to office suites, from home-developed apps to big
> commercial bloatware (oo)
>
> All the things you're clamouring for *have not a single technical
> justification*. Period. You don't want them because the user needs or
Software components: Take a look at OOo, Mozilla, GNOME, etc. - a user
installing these has to manually pick apart and selected packages. A
user-friendly approach would, upon opening the installer, give them
options to select among options - i.e., do I want just the browser, or
the mailer as well, or the browser, mailer, calendar but not the chat
program, etc.
When we get into managing packages, the user will see a list of things
like:
mozilla-browser
mozilla-mailnews
mozilla-chat
mozilla
mozilla-nspr
mozilla-nss
etc.
That's just insane. Those are all "Mozilla", just different
sub-components. When you toss in things like virtual packages that
exist solely to depend on everything (common in Debian, less common in
RPMs), the user model *really* starts to suffer.
What happens when an application spans multiple CDs? I have tons of
software like that - games, music composition applications, etc. - how
does RPM handle that? Oh, right, it *doesn't*. Unless the author
breaks the app into multiple RPMs, which is (a) insane, and (b) pollutes
the package space.
> wants them, or because they will improve the system. You want them so
> people can use Linux just like another windows, with just the same
> habits that ruin everyday windows user life, and so commercial houses
> can issue the same junk as they are used to.
Seriously, this is nothing but paranoid rambling. I'm not going to
waste time trying to debate with a raving zealot - discussion over.
--
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.
More information about the fedora-devel-list
mailing list