Filippo Giunchedi a écrit :
[opening a new thread, since it was the original idea]
On Thu, Mar 01, 2007 at 02:59:59PM +0100, Stefano Zacchiroli wrote:
I'm more worried about how you choose the environment you want to
dist-upgrade. Various criteria that come to my mind (braindump):
- base system only (pro: easy to set up, cons: tests a too small set of
package)
- \forall task, base system + 1 task (pro: still easy to set up, tests a
lot more packages, I guess all tasks taken together are a fair share
of the packages in the archive, cons: do not upgrade issues induced by
inter-task relationships)
- base system + a set of random selected packages (pro: easy to set up,
tests inter-task issues, cons: non-idempotent, i.e. not easy to
reproduce, no guarantees/idea about how much of the testing domain has
been effectively tested)
I would add:
- base + most popular packages (arch-wise, modulo together-installability)
- base + largest set of packages installable together (there's more than one)
the above sets can be found with the aid from the edos project, I had a quick
look at their tools but can't find an obvious solution.
Hello,
I'm in the edos project, and there are I think 2 set of tools which can
be usefull:
- dependencies management tools, probably anla, but I don't know the
dependencies management tools enough in depth to give you a usefull
answer. I have forwarded your mail to the people in charge of these tools
- testing tools, namely TULIP, which is a distribution upgrade testing tools
TULIP uses qemu to run automatic upgrades on 'virtual' installations;
this way, you can test the dist-upgrade of several environments. The
cons is that it is quite slow.
There is more information about TULIP on:
http://www.edos-project.org/xwiki/bin/view/Main/TULIP_tool
I think we have already an experimental TULIP installation working on
Debian dist-upgrades.
François
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
