Re: Is this really the right thing to do?

[Ed Cogburn <ecogburn@greene.xtn.net>]

Mitch Blevins wrote:
> 
> Ed Cogburn wrote:
> > Mitch Blevins wrote:
> > > One problem with auto-deinstallation of support packages is that
> > > you may have other packages that also use the same support package.
> > > You would have to grep the dependency database to  ensure you
> > > weren't removing a library/package that was used elsewhere.
> > > Even then, you may have programs in /usr/local that are not tracked
> > > by dpkg and need one of those libraries.
> >
> >
> >       If dpkg kept track of all packages that depend on the one we are
> > talking about, it could 'know' when the package is no longer usefull and
> > is merely wasting space.
> >       About usr/local:  since we are talking about deb packages, I don't
> > belive there would be a situation where a deb package in the
> > distribution is dependent on a library that must be installed by the
> > user.  Most deb packages in the distribution are dependent only on other
> > deb packages.  The Netscape program that untill recently relied on a
> > 'installer' deb is an exception, though, but now NS is in deb packages
> > (in slink) so that exception is no longer valid.
> 
>  I was speaking of the case where you have a /usr/local binary that
>  depends on a shared lib that is in a .deb


	See below.

 
> > > You also have support packages that are obviously useless by themselves
> > > (such as libraries), but what about the ones that are only 'semi-useless'
> > > by themselve.  An example would be a documentation package.
> > > Suppose you want to have foo-doc installed without foo. (an avid reader)
> > > foo-doc would be part of the foo 'group', but can still be considered
> > > useful without foo.
> >
> >
> >       I guess that it would be up the maintainer to signify whether their
> > packages are support-only, or usable-on-their-own.
> 
> The maintainer doesn't always know best.  Centralization is bad.
> What if I want to build the latest foo from CVS that depends on
> the libfoo.deb package.  I don't want foo.deb, but I do want the
> support package.  The maintainer cannot forsee all the different
> scenarios.
> 
> -Mitch
> 


	Yes, /usr/local is a problem.  Well, perhaps this method could include
an 'override' for any package that would suppress dpkg's indication that
a deb package has been orphaned.  The user who as developed a
/usr/local/ binary that depends on an installed deb, would take
responsibility for keeping track of these things.  Since debian policy
keeps a firewall between /usr/local/ and the rest of the dpkg maintained
system, these kinds of interaction problems are already happening to
some.
	It depends on how much /usr/local/ is being used by debian's users. 
When I started with debian, I had a half-dozen things I was keeping in
/usr/local/ and taking responsibility for.  Over the last year or so,
most of these software progs have been adopted by deb maintainers and
are available as deb packages (even the Atari emulator, Cool!, :-) ). 
So I'm down to using /usr/local/ for only one prog (which is available
as a deb) that I want to compile myself.

	It seems to me that one of the things about Debian is its
centralization of software packages (and their management) of the
system.  I think most of us would say it has been beneficial.  I
personally think its better than the tarball anarchy of Slackware  :-). 
As long as this method we are talking about can be overridden by a user
option, I don't believe it would cause unnecessary centralization.


-- 
Ed C.