[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is this really the right thing to do?



Ed Cogburn wrote:
> [snipped for brevity] 
> 
> 	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.

See the discussion on the fork of this thread on debian-devel.
I believe the currnt discussion is of an 'Auto' boolean status flag
for each package.  The flag means that the package will be automatically
removed if all packages that depend on it are removed.  This flag
will be automatically turned on for each package that is installed
because it was Required by another package, and not installed explicitly.

This would allow easy installation and removal of groups of packages
using the standard dpkg dependency fields.  I believe this would satisfy
your desire for package grouping.

-Mitch


Reply to: