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

[Nicolas Mailhot]

Le dim 12/10/2003 à 17:56, Mike Hearn a écrit :
> On Sun, 2003-10-12 at 00:14, Sean Middleditch wrote:

> > That would be interesting.  The problem is, then, every single app that
> > possibly exists in the application/dependency archive would be in the
> > menues.  Ick.
> 
> No, only stuff the user had installed.

Please keep unstalling/uninstalling out of menus.

Windows only does it because for a long time they installation manager
panel missed most apps (and still misses some of them). So people had to
put uninstall links somewhere else. Really it's amazing how people
forget history and comme to accept ugly workarounds as the natural way
to do things.

We don't need no windowish in-your-face uninstall solutions, we don't
need popup eulas, change-install-location dialogs,
here-is-the-disc-size-I-need-please-check windows,
you-think-I'm-installed-but-check-my-20-pages-readme popups,
don't-bother-with-permissions-and-run-everything-as-admin

(I case people wonder - I've just documented the installation of an app
that used a custom installer clearly written by a brainwashed
monopolysoft user. Just documenting this single installation took as
many pages as the ones devoted to updating the whole multi-hundred rpm
system)

Anyway I don't know why I bother - just do your thing and I'll watch HiG
people shot it down.

> > While I understand the use cases, as I've said on the autopackage lists,
> > and real Application Manager is needed (which I've some new ideas for,
> > i'll post those to the ap list).
> 
> Please do so. I'm not sold that we need any specific app management
> program - it's the sort of thing users just never think about (much like
> uninstalling stuff they no longer use).

Sure - why use a single consistent working solution when you can let
everyone reinvent incompatible wheels ?

> > Which isn't really possible.  The best you could do is inform the user
> > that the system doesn't *appear* to be using the app anymore (no users
> > have a launcher for it, if you can even determine that easily) and let
> > them optionally uninstall it.
> > 
> > The same is true to libraries/dependencies - sure, normal users might
> > not need them if no other packages are using them, but hackers/admins
> > probably have a lot of stuff installed from source.  So automatic
> > dependency "garbage" collection isn't really feasible, at least not
> > without lots and lots of user interaction and such.
> 
> Maybe.... still, it's been done in Java/C# for ages, despite the
> difficulties. It seems unintuitive that it's possible with objects but
> not packages.

Well I can tell you we have *nothing* to learn from java packaging,
quite the contrary. In fact the java world right now is a motherload of
bad packaging examples.

> > Evangelism on the importance of proper development practices could be
> > useful, too.  Probably the only place I've seen describing library
> > versioning in detail is the innards of the libtool manual.  No wonder
> > lots of devs don't do it right, eh?  Something like the war on drugs is
> > needed: DARP, Developers Against Ramshackle Packages.  ;-)
> 
> Yeah, I want to do this too at some point, probably as part of the
> packagers/developers guide we're writing for AP. There is a good paper
> by Ulrich Drepper on writing DSOs, but it's basically impossible to find
> unless somebody shows you. Other bad techniques are compile time
> options, non-relocatability and so on. Developer education is definately
> a part of the solution.

Developer education will *always* be a problem. Developing and packaging
are just two different CS specialities (just like developing and QA).
Some people will do both, most won't, expecting every single developer
to be able to package things is just a recipe for bad packaging.

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/63cc9dc5/attachment.sig>