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

General exclusion-package package (was: Bug#138541: ITP: debian-sanitize)



On Sun, Mar 17, 2002 at 12:21:00PM -0800, Craig Dickson wrote:
> I really don't see a problem with anyone putting a package in that
> expresses their personal opinions about the appropriateness of various
> packages

I'd rather not see a proliferation of such packages at all.  Furthermore,
the general problem here has nothing to do with morality.  People and groups
all have their own reasons for wanting to exclude certain packages, or
certain kinds of packages from their systems.  Debian should support the
administrators' desire to determine what packages they *don't* want on their
system as well as what packages they do want.

Why shouldn't an administrator be able to put their own policy into effect
about which packages are verboten without needing to know how to write a
Debian package? For example, if administrators don't want "instant
messenger" packages of any sort installed on their systems, they should be
able to list the offending packages (or use someone else's list of instant
messengers) in a conf file, and then install the whole system with the
assurance that the undesirable packages are not installed via some task that
may attempt to pull in one of the "offending" packages.  (I understand that
tasksel will now happily install a task even if one package it depends on
cannot be installed.)

So why not make a general-purpose "exclusion-package" package, tailorable
per site via a conf file.  This package would build a local exclusion
package using the conf file of exclusion rules (grep-available may come in
handy here to translate the rules into a list of packages) to construct the
"Conflicts" field.  Every time the list is updated, run "update-exclusion"
to generate the exclusion package from the conf file rules and have it
automatically installed (probably with a final conflict list
review/confirmation step beforehand).

Taking this approach, the creation and maintenance of exclusion lists
becomes the domain of concerned admins, not of developers.  That is how it
should be, IMHO.  If a third party wants to take on the responsibility of
"screening" Debian's offerings and providing conf files on their site that
will serve a certain subgroup of Debian users, they may now do so.

Ben

p.s. Sorry if this duplicates someone else's idea ... the original thread
     and all of its subthreads bored me to tears, so I didn't read every
     single response.

p.p.s. At one point some fool tried to start copying these threads
       to the debian-jr list.  Thankfully they botched it and spelled
       the listname debian-junior.  I'm not terribly interested in
       perpetuating this silly debate on my list, thanks.  But I did
       want to point out the error in case others reading this are
       confused about where our list is.
-- 
    nSLUG       http://www.nslug.ns.ca      synrg@sanctuary.nslug.ns.ca
    Debian      http://www.debian.org       synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]



Reply to: