Re: Status of lxde
On Sun, 2010-05-23 at 21:30 +0800, Andrew Lee wrote:
> What is the current situation/plan with lxde's transition to testing?
Apologies for not getting back to you sooner.
We've recently (finally) managed to narrow down the location / cause of
the issue but haven't yet found a solution. Feel free to skip some of
the explanation below; it's partly to make sure the details are
documented, and in case they provide anyone with any inspiration.
To recap, britney believes that migrating the new lxde packages to
testing would cause the tasksel-meta-faux package to become
uninstallable; t-m-f is a fake package which is injected in to the i386
packages files processed by britney, to ensure that all packages listed
by tasksel as "core" to any task remain installable. Unfortunately
attempts to reproduce the problem by other methods, such as installing
the involved packages in testing chroots or force-migrating the packages
in a test britney run and running edos-debcheck on the resulting
packages file have been unsuccessful.
I've managed to produce a "minimal" test-case, in that using "lxde-core,
gnome-desktop-environment" and ignoring the other packages normally in
t-m-f causes the issue. Considering the co-installability of those two
packages leads to a sufficiently high number of packages being
considered that britney's dependency resolver aborts the test; I've
tried increasing the limit, but so far only with the same result after a
longer wait.
As the order in which packages are considered can make a difference to
the number of packages which need to be checked I've also been
experimenting with "expanding" g-d-e to its component packages but have
not yet found an ordering which works. Maintaining this in the longer
term would also not be ideal, as the list is generated from tasksel's
data files, which include g-d-e, and is not explicitly ordered.
I've confirmed that forcing lxde in to testing appears to produce no
issues other than the tasksel-meta-faux uninstallability; the problem is
that by doing so we would lose the ability to detect any further issues
with the co-installability of the package set, as they would not
increase the count of problems in testing.
This mail has ended up being somewhat longer than I'd intended, but
hopefully it's useful.
Regards,
Adam
Reply to: