sane dependencies -- a positive look at 'fix your packages'

[Nicolas Mailhot]

Le dim 12/10/2003 à 00:22, Mike Hearn a écrit :

> Right. I quite like the idea of a non-technical user browsing to
> frozen-bubble.org, and seeing the icon embedded in the web page. They
> drag it to the panel, or perhaps even just click it in the webpage
> directly. The button starts glowing or something to indicate that the
> computer is working, and the process of installation gets going in the
> background. When it's done, the icon goes coloured, maybe with some
> pretty sparkly effect to indicate "newness", and the program launches.

Yeah and when you've done this you've also got virus, trojans, worms and
general system instability.

You can not trust just any random web page/gpg key/packager/whatever.
Distributions provide quality packaging, software review, system
consistency, etc (that's one of the reasons all the distributed software
projects that were proposed won't ever fly IMHO - there is no way so
many different actors with different priorities, backgrounds, deadlines,
etc can agree on a common set of rules strong enough to maintain the
overall quality a current distribution provides)

Now in the past one could say distros do not cover a large enough
spectrum. With projects like Fedora this is no longer true - you want
your app in Fedora just submit a quality package and it'll get in. Then
people will install it because they *trust* the Fedora signature/label.

Making a quality package is *hard*. Computer systems are *complex*. And
working outside of a big distribution-like project only makes packaging
*harder*.

Most of people who complain just want to offload crap packages on the
user like in the windows world. As someone who is regularly called to
clean up the damage these habits cause I respectfully disagree. It says
a lot that an experimental system like Rawhide often behaves better than
your average windows setup.

If you want to enlarge the packaged perimeter just mount a packager
group on which upstream projects can offload packaging problems.

If you think distributions are the problem (like autopackage people
obviously do) just get all people that think like you together and have
them agree on a common distribution method. I predict that the best
outcome will be yet another distribution (and the probable one utter
failure - people who don't want to package stuff cleanly now won't do it
tomorrow in another organisation)

There is one point I agree with you - it'd be cool if upstream projects
could more easily provide install profiles so people can use their stuff
after reading the web site. And this can be done pretty easily by a
comps.xml adaptation that would be fed to the local apt/yum/urpm that
would then pull relevant package_s_ from the *distribution* repository.

(and yes the package/profile separation is needed. I want to be able to
provide a artist profile and a tester profile, for example, and they
will both include the gimp package, because testers need to provide
annotated screenshots too)

And while there is room for gfx effects the core engine must be CLI/GUI
independent. I can assure you after the second installation you quickly
tire of the bloody widgets and yearn after something you can just run in
a ssh window/crontab/script. People will probably want to collect all
the profiles they commonly use on a floppy and feed all of them in a
single operation to the package manager of their new computer.

(think "modular kickstart")

> The app is now available from the menu, the web page, can be dragged to
> the panel/desktop/whatever. User decides frozen bubble is really cute,
> and opens up their chat program and drops the icon (the application, in
> effect) into the chat window, where it appears the other end grayed out
> and the process begins again. If that other user is on PowerPC and lives
> the opposite end of the planet, no problems, the right download is
> selected from the right mirror.
> 
> A lot of work, obviously, but all doable. First of all you need an easy
> way to build distro-neutral packages. From my experiences, I'd say the
> LSB is not it....


There is no easy way.
You want to do distro-neutral packages ? Fine.
Just be damn good.
The day someone in one of your target distros release a better package
than yours poof you've instantly lost part of your target audience.

Remember : distro-specific packagers have this advantage they can use
all kind of fun "extensions" when you can't.

Realistically that means :
1. do not try to repackage stuff that's already in the distributions
2. follow strictly FHS and the parts of LSB that make sense - be
stricter than the others packagers you'll compete with
3. package a large enough pool of interdependent software people won't
be able to take "just one bit" and make it distro-specific easily
4. have a team with people that regularly use all target distros
5. use file names not package names as dependencies - distros will
rename/split/merge packages but the FHS will force them to use the same
file locations
6. use an apt+yum+urpmi repository to reach as much people as possible
7. whenever disto X has cool extension Y you want to use gently push Y
for inclusion in the other target distributions

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/20031012/22b4b15d/attachment.sig>