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
Reply to: