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

Re: APT [was Re: Is this really the right thing to do?]

Jiri Baum wrote:
> Hello,
> >  Before proceding with my proposal, let me define a term for packages
> >  that are installed for no other reason than to satisfy a dependency.
> >  I think 'Hooked' is a good word.  It is a synonym for 'dependent', and
> >  it can lead to many good fishing analogies. ;)
> A better word might be 'Wanted' (inverse of Hooked).

 Good word.  But do you think that might be confusing because of the
 fact that these packages are not 'wanted' by the user unless they
 are required as a dependency?

> It might even be better to have it a string field, so the admin can note *why*
> it was wanted - like this:
>   Wanted: for J. Random Luser's xyzzy project
> or
>   Wanted: by /usr/local/bin/plugh
> I think it would be a good idea if, before actually deleting packages, the
> admin was shown their list and given a chance to mark any of them wanted.

 Maybe I wasn't clear.
 A 'Hooked' package is one that is only installed because it is a dependency
 to another package that is installed.  Therefore, it can be safely
 (and automatically) removed when all packages that depend on it are
 removed.  Library packages are a good example.

 A string field would not be needed because apt/dpkg would already
 know which packages depend on it.  The only info you are supplying
 by marking it Hooked is that it is okay to remove it if it is not
 required by another package.

 I envision it as a single-character column in apt, similar to the
 'Status' column.  Having an easy way to see which packages depend
 on another package would be helpful in deciding whether to mark
 a package as Hooked, but that is more of a UI issue.

> To make this worthwhile, suite packages would then need to be produced. These
> would be packages which contain almost no files, but recommend/suggest a bunch
> of other packages (eg a "C development suite", recommending gcc, libc6-dev,
> kernel-headers, etc and suggesting gdb, lint, prof). Most people would then
> mostly select the suites, greatly reducing the number of packages they need to
> come in contact with.

 It would be worthwhile even without any suite-packages.  But you are right
 that suite-packages would then be possible and useful.  You could easily
 install a suite and safely/easily remove it even if other suites or
 packages depend on a component of your suite.
 The "C development Suite" is a good example.
 You could also have a "C++ development Suite" that had overlapping
 packages with the "C development Suite".
 An "Enlightenment Suite" would be another example of a program that could
 benefit from this.


Attachment: pgpRk_GyHxrfU.pgp
Description: PGP signature

Reply to: