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

Re: Essential and Packages files vs /etc/.

On Tue, 16 Mar 2010 01:10:10 +0100
Wouter Verhelst <wouter@debian.org> wrote:

> On Sun, Mar 14, 2010 at 10:02:22PM +0000, Neil Williams wrote:
> > .... and having Essential in the Packages file makes it harder than it
> > could be to avoid Essential if the list was in /etc.
> If the list is in /etc, an ignorant user may modify the list (remember,
> /etc is system-local!) and break their system.

It is a system-local implementation that would be the only way of
preserving Essential for my purposes. If not system-local, at the most
"device-type" specific. (Where device-type is not desktop vs embedded
but embedded variant A vs embedded variant B - we all know how often
devices change variant ....)

The chances of a user being able to access /etc/ on an embedded device
are lower than on a desktop machine and some might not allow any
authorised access to /etc/. Some systems might offer a synaptic-type GUI
interface without having any hardware to support direct terminal access,

> It is a *good* thing that Essential is hard to modify.

It leads to an all-or-nothing situation - Essential contains too many
packages for any embedded device and those packages cannot be replaced
without removing all (because nobody can afford to have an entire
repository per system).

I'm wondering if an apt configuration setting could be devised that
tells apt/aptitude to use a file in /etc/ in situations where no
Essential tags exist in the Packages file. Emdebian could then continue
to remove all Essential tags from package control files but allow some
systems to specify their own list of Essential packages and Debian
could continue with a hard to modify list. A kind of
"Essential-fallback" option.

If Essential is worth having, there needs to be a way of implementing
it without changing the archive every single time - even possibly
changing it on-the-fly. Either that or just have no Essential at all.


Neil Williams

Attachment: pgpwcI1Pky63u.pgp
Description: PGP signature

Reply to: