Re: Introducing DoudouLinux

On Mon, Aug 15, 2011 at 11:03:31AM -0300, Ben Armstrong wrote:
> Explain why this is better than pinning.

It is not *better* but it introduces a different/additional concept.
I also do not see in how far this can help for creating an install
medium using debian-life (or something like this).

> With pin priorities I can, as
> the admin, decide whether to pin some package to mean "never" or just
> "not now". Different admins will have different desires. Dependencies of
> a metapackage cannot be overridden by the admin without removal of
> the metapackage, so unless the metapackage's explicit and sole purpose
> is censorship, I don't think a metapackage with conflicts is a useful
> technique.

I think we discussed this in the past. :-) Besides it is not implemented
yet because there was no practical need I do not buy the argument of
those different admin needs: If admins are grown up enough they probably
will not use the Debian Jr stuff any more.  For a first shot to Debian Jr
the answer: Simply install the metapackages is more easy than explaining
pinning in addition.

However, the discussion might become a new quality now since we might be
able to feed files into /etc/apt/preferences.d inside metapackages.  Are
you actually talking about this?
 
> >   - really large data file which can be used as alternative to one
> >     smaller sized package and both alternatives are enabled by the
> >     package using the data but we explicitely want the small package
> > 
> > I'd regard these as possible use case for a Conflicts inside a
> > metapackage.
> 
> The case is even stronger against Conflicts here, as size is a
> constraint that changes from one use case to the other. If you make a
> metapackage that conflicts for size optimization on a CD, you force the
> admin to remove that metapackage if they use the CD with, say,
> persistence enabled in order to grow & install more packages. With
> pinning you can say "not now" and give the admin the option of adding
> the extra "too big" data later if they wish without having to remove a
> conflicting package.

I think the discussion about not yet implemented stuff is not fruitful.
I just imagined some options we might have.  I'm not going to implement
this in the foreseable future (except if there are really strong
reasons/requests).

Kind regards

        Andreas.


-- 
http://fam-tille.de