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

[Sean Middleditch]

On Sun, 2003-10-12 at 12:51, Nicolas Mailhot wrote:
> 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.

I think perhaps you aren't following Mike's intent - the Windows way,
adding big menu options for "Uninstall", is not what he meant.  More,
when you context-click on an app in the menu, several options pop up
(copy launcher, remove from menu, etc.) - one of those would (could) be
"Uninstall application".  Completely out of the way unless you're
looking for it.

> 
> 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

In many cases, we *do* need some of those.  We *do* need EULA support,
for example, since applications I install often have them.  Whether or
not you think they're evil, others need an installer that supports them
(versus the RPM way, which requires packagers to wrap the RPM in a shell
script which I then have to run in a command line to open, agree to the
EULA, and then install) as they use applications that have them, and
need to continue doing so.

> 
> (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)

Ya... let's keep this to technical facts, not "brainwashed Free Software
user" paranoia.  Thanks. ;-)

Installation problems on Linux I've run into are almost always because
of RPM.  If RPMs usually supported more than on particular snapshot of a
particular distro, if RPMs actually worked on all distros, and if RPM
had abilities to ask users install questions, select software
components, agree to legally-required EULAs (there's doubt that even the
GPL is really valid if the user is never forced to agree to it, or even
*see* it, to use the software), etc. then software developers probably
wouldn't need to rely on hacked-up installers.

As is, even most of the companies that ship RPMs generally need to wrap
them in shell scripts or other hacks in order to "add" the features RPM
denies them.  Look at the Macromedia Flash, Adobe Acrobat Reader, or Sun
Java installs (I think those are the ones that use wrapped RPMs), for
example.

> 
> 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 ?

That isn't the intent.  The idea is to put the "single working solution"
somewhere other than a monolithic GUI manager.  Altho, personally, I
still think the GUI manager is a necessity.

> 
> > > 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.

There are *huge* differences, unfortunately, between an application
running and applications spread all over the file system.  Garbage
collection in Java/C# doesn't happen across two apps connected over the
network, yet application garbage collection would need that for mounted
shares/volumes.  Memory garbage collectors also have access to all
objects in existence, and (in good implementations) know when object
relationships are formed or broken - an application garbage collector
would need to somehow find out whenever any reference to an app has
changed.  Memory collectors also don't support fancy memory tricks like
"hidden" pointers and such, but an application garbage collector would
need to know about "fancy tricks" like users using an app from the
command line or a script and not .desktop files.

Memory GC and application GC are really just two completely different
things.

> 
> 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.

Developers don't necessarily need to package.  They *do* need to not be
so boneheaded as to make packaging impossible.  i.e., when the packager
comes along and finds out that the only way to get "lite version" and
"full version" of the application packaged is to make them conflict with
each other, thus requiring a user to uninstall and reinstall the app to
"enable" features, the packager should bring the issue up with the
developer, who then should go, "oh, oops, will fix this!" and resolve
the problem on his end, allowing the packager to make sane, working
packagers that people besides l337 h4ck3r5 and sysadmins can install and
use.

As is now, the developer tends not to give a flying hoot (or just not
know any better), the packager can't resolve the issue with the
developer (or they themselves don't really understand the problem), and
we end up with tons of packages that don't really work unless installed
in one specific OS setup, when the moon is full, the stars are aligned
properly, the wind is blowing from the south-southeast at 45 knots, and
you've your ritual RPM body paint on with shell script incants written
all over your forehead.

Evangelism and education can help this.  Simply not packaging brain-dead
broken software helps too; or, at least, understand that packages of
software like that should be the *exception*, not the rule.  We'll
probably always have a couple pieces of popular software written by
dinks that think Linux should only be for the technologically elite and
kept away from "dr00ling lusers," but hopefully we can keep that to a
minimum.

> 
> Cheers,
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.