Andreas Tille <tille@debian.org> writes: ... > As far as I understood Phil's last posting he is working on an enhanced > tasksel. Actually, what I've been working on is infrastructure to allow others to contribute to such an effort. I've recently enabled a CI pipeline in the tasksel master branch, so anyone forking that will now get the benefit of this work for free (as long as they set the CI file to be 'debian/salsa-ci.yml'). I intend to blog about the details shortly, but a quick run down is that this pipeline was triggered by a commit to my fork: https://salsa.debian.org/philh/tasksel/-/pipelines/337031 which (via a multi-project pipeline) generates a mini-iso: https://salsa.debian.org/installer-team/debian-installer/-/jobs/2364015/artifacts/file/public/gtk-mini.iso that is configured to use an additional apt repo, which in this case includes a version of tasksel built from the above branch: https://salsa.debian.org/installer-team/branch2repo/-/jobs/2364013/artifacts/browse/public/pool/main/t/tasksel/ which one can then download the min-iso for testing, and/or cause to be automatically tested with openQA, as seen here: https://openqa.debian.net/tests/overview?groupid=13&build=-salsa-337031:philh:tasksel:salsa-CI_tasksel where if one drills down to the logs, and search for 'salsaci', one can see that the tasksel packages came from the extra repo: https://openqa.debian.net/tests/37964/logfile?filename=_collect_data-debs.txt The same is true for udebs that are included at build time, and that would be expected to be downloaded at d-i runtime, so simply by creating named branches with the same name across all the (u)debs that one wants to test together you can get hold of a mini-iso that will use those versions in preference to the released versions, without needing to know anything about building d-i or debian CDs. Hopefully that lowers the bar enough so that people can concentrate on the bits they want to improve without immediately getting stuck on how they could possibly test their efforts. However, I've not really put much thought into what actually needs to be changed in order to address the Blends Selection problem. In the past when this has come up I've come up with some temporary hacks that worked around the lack of a decent user interface, but if we want to fix this properly then I think Steve has a point that one way to do that is to extend debconf, and then use new features in tasksel. I don't have anything like a design for how that should look in my head though -- I guess interested parties should get together and come up with a design _before_ we start trying to implement it :-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature