Re: utnubu-desktop for the masses
On Sun, 2006-04-23 at 13:57, Joey Hess wrote:
> In the head of this thread, I posted a message listing several problems
> with metapackages. All of these problems may not apply to all
> metapackages at all times, but in sum they all apply in general and are
> a good reason not to use metapackages for tasks and to limit the breadth
> of metapackages in Debian.
* "Clogging Britney" is subjective.
* "General fragility" is subjective.
* "All or nothing" is irrelevant. You don't have to use meta
packages if you they don't meet your needs.
* "Lack of clean removal" is irrelevant. You don't have to use
meta packages. If you do use meta packages, there's always
deborphan and friends.
Therefore, rather than wander off into subjective arguments
and irrelevant issues, let's focus on the significant issues.
The only significant issue yet identified in this thread is
testing migration.
> You have so far concentrated on how a single facet (testing propigation)
> of a single problem (britney scaling issues) of a single task (desktop)
> might not be a problem. While beating the details of an edge case to
> death is an interesting debating technique (or perhaps just a good way
> to get everyone else to go away) it's not likely to lead to anything
> generally useful.
A reasonable software heuristic is to first solve the easiest
case, then the hardest case, and then all cases.
The desktop task is apparently the hardest case, and such is
worthy of consideration.
> So far this entire thread has managed to be a useless distraction from
> the question at hand, which is how to make Debian's desktop task the
> best collection of packages it can be. I hope that if Gustavo hasn't
> been scared off by the predictably useless evolution of this thread so
> far, he will still find a way to work with me to help improve things in
> this area.
The thread started with your criticism of Gustavo's incorporation
of meta packages. The subject of improving Debian's desktop task
had not previously been mentioned in this thread[0].
> > tasksel is a separate parallel unnecessary superfluous redundant
> > and largely opaque dependency lattice with some dependencies not
> > even determined until runtime (Test: ) and a whole set of action scripts
> > (postrm etc) independent of regular package scripts.
>
> Your rhetoric is boring me.
>
> "dependency lattice" has no meaning.
"lattice" is a traditional name for a directed acyclic graph,
which is what we strive for in dependency management. Etch
actually contains a hundred or so dependency loops right now
but most of them are trivial, e.g. the mutual dependency
between gamin and libgamin0. Such cliques are treated as
single nodes in the DAG.
> The "Test:" fields have nothing to do with dependencies and could not be
> implemented using normal packages.
A "Test:" script result of 0 causes the task to be silently
installed. A "Test:" script result of 1 causes the task to
be silently not installed. (There are other possible exit
codes which result in other actions.)
Thus a "Test:" script determines whether or not a package
is to be installed by an arbitrary and opaque runtime
calculation. It is a runtime calculated dependency rather
than a declared dependency. This prevents any dependency
manager from analyzing these dependencies without replicating
chunks of your tasksel code and executing them in a simulated
environment.
> Tasksel's sole "action script" is desktop.preinst, which could not be
> implemented using any regular package maintenance script or dependency
> mechanism, since X requires the hardware detection programs be installed
> before it is preconfigured. In making X operate this way, the X
> maintainers have *required* that the installation system have a special
> case for X; castigating tasksel because I chose to implement support for
> this special case in a generalized fashion in desktop.preinst is absurd.
Since there is a consensus that this will go away, we can
handle it as a special case until then.
> Please take your offtopic bullshit to /dev/null.
It's been a pleasure discussing this with you[1].
--Mike Bird
[0] http://lists.debian.org/debian-devel/2006/04/msg00744.html
[1] Not all statements in this email are true.
Reply to: