On 6/2/05, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote:
> > Yes, I cannot deny that the last 2 weeks spent packaging nonfree
> > software has greatly influenced this post. :) That, plus the sad fact
> > that even though several vendors provide .rpm files, they are utterly
> > unusable because they try to be installable on as many things as
> > possible, and always end up sucking on all.
>
> so basically the fap layer is only really a target for nonfree
> software... but clearly
> its doomed to fail because the pre-existing conditions for it to be
> used successfully are not going to be met
>
> if proprietary vendors can't package rpms correctly.. the fap layer
> doesn't help.
> if proprietary vendors can't create repos correctly.. the fap layer
> doesn't help.
>
> I have very little faith in proprietary vendors doing either correctly.
Well, not exactly. The problem currently is that the only relatively
standard packaging format available to vendors is .rpm, which works
great when there is one distro, and not so great when there are many
(the famous "rpms just create dependency hell" complaint). So, vendors
have several ways out:
1. Don't bother and ship tarballs with a #!/bin/sh installer. Have
some sort of an asinine custom updating mechanism, or none at all.
2. Create a long list for user to choose from:
* download this if you are running Suse 8
* download this if you are running Suse 9
* download this if you are running Fedora Core 2
* download this if you are running Fedora Core 3
* ...
...which they rarely do, since they think it confuses users, and
because some users only have a vague idea what distribution/version
they are running. If the vendor ships kernel modules, then this list
grows exponentially (see NVidia download page for examples). No
updating mechanism available.
3. Create one RPM that statically links most things, and tries to work
on anything by having horrendous staircases of %if-%endif, and by
installing everything in /usr/local and hoping things still work. No
updating mechanisms available.
A super-package mechanism would help create a framework that would
allow addressing the problems listed above. I'm not saying that
vendors are guaranteed to use it (and not abuse it, or use poorly as
they are wont to do with anything NIH), but if a mechanism is in place
that makes things for them easier and convenient, then at least there
would be a compelling reason for them to at least do something about
the pitiful state things are in at the moment.
Regards,
--
Konstantin Ryabitsev
Zlotniks, INC
"Выслухаў мядзьведзь казку і адарваў сабе хвост."
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
