I would like to push a proposal here on this longstanding topic:
By other means, my attention was drawn to the blends-tasks package.
While this package is not new, an idea came to my mind when reading the package description:
As a possible way to solve (or work-around ?) this issue:
could we just "copy tasksel with its UI and infrastructure" into a new package
(I name it 'blends-di-tasks' here), which has all the blends listed, and add one entry to tasksel with a name like "Debian Pure Blends" or similar?
If one then selects "Debian Pure Blends" in the good all known tasksel, the blends-di-tasks package would be installed on /target, and later a new dialog would appear, listing all the blends, where the user could select which one to
install.
(If the "Debian Pure Blends" entry stays unchecked, as would be the default value, everything stays as is: the new dialog would not appear, no difference to previous releases.)
Would that be a possible solution for all involved parties?
I know, the current (?) plan is something like an "enhanced tasksel" with some
sort of hierarchy included, but I'm not sure, if this will ever happen....
Thus, I wonder if this could be an alternative, which would be do-able?
Holger Wansing <hwansing@mailbox.org> wrote (Tue, 13 Feb 2024 23:43:35 +0100):
could we just "copy tasksel with its UI and infrastructure" into a
new package (I name it 'blends-di-tasks' here), which has all the
blends listed, and add one entry to tasksel with a name like "Debian
Pure Blends" or similar?
If one then selects "Debian Pure Blends" in the good all known
tasksel, the blends-di-tasks package would be installed on /target,
and later a new dialog would appear, listing all the blends, where
the user could select which one to install. (If the "Debian Pure
Blends" entry stays unchecked, as would be the default value,
everything stays as is: the new dialog would not appear, no
difference to previous releases.)
Would that be a possible solution for all involved parties?
So, how to proceed now?
To make progress, the new blendsel needs to get into the archive I guess, otherwise testing and providing test images will not work IMO.
Would the installer-team be ok with taking blendsel under its umbrella,
as tasksel is, to get it uploaded?
Would the installer-team be ok with taking blendsel under its umbrella,
as tasksel is, to get it uploaded?
Looks good to me.
Now blendsel being moved to installer-team, would you mind giving me
dm permissions, so I can upload? Thanks
Holger Wansing <hwansing@mailbox.org> wrote (Tue, 13 Feb 2024 23:43:35 +0100):
could we just "copy tasksel with its UI and infrastructure" into a new package
(I name it 'blends-di-tasks' here), which has all the blends listed, and add
one entry to tasksel with a name like "Debian Pure Blends" or similar?
If one then selects "Debian Pure Blends" in the good all known tasksel, the blends-di-tasks package would be installed on /target, and later a new dialog
would appear, listing all the blends, where the user could select which one to
install.
(If the "Debian Pure Blends" entry stays unchecked, as would be the default value, everything stays as is: the new dialog would not appear, no difference
to previous releases.)
Would that be a possible solution for all involved parties?
I worked on this in the meantime, and would like to propose my current
state:
- I adapted tasksel, to become an installer for Debian pure blends. The
new package is blendsel, see https://salsa.debian.org/holgerw/blendsel/
- I prepared a change in pkgsel, to call blendsel depending on the
descision, if Debian pure blends are wanted or not.
See https://salsa.debian.org/holgerw/pkgsel/
I did some testing in d-i, however that's tricky:
testing is problematic as long as the new blendsel package is not in the archive, and the same with the changed pkgsel.
So I had to "live-patch" the d-i for testing of blendsel, and therefore
I cannot provide a working test image or the like (or I don't know how).
Anyway, I think I have it running so far, the blendsel dialog appears
and shows the items to select; I'm attaching a screenshot showing the
current state (please note, that the dialog shows three desktop environments as placeholder for now; the tasksel - and therefore blendsel as well -
logic does not allow to have packages|tasks|blends listed that don't
have the corresponding task-* packages in the archive).
However, there will most likely be some glitches and edges to fix in blendsel, a review would be more than welcome...
The template should be rephrased, I would ask for review on debian-l10n-english
when the time comes, but I guess there is still time for that...
So, how to proceed now?
To make progress, the new blendsel needs to get into the archive I guess, otherwise testing and providing test images will not work IMO.
Would the installer-team be ok with taking blendsel under its umbrella,
as tasksel is, to get it uploaded?
I did some testing in d-i, however that's tricky:
testing is problematic as long as the new blendsel package is not in the archive, and the same with the changed pkgsel.
So I had to "live-patch" the d-i for testing of blendsel, and therefore
I cannot provide a working test image or the like (or I don't know how).
which when tested on openQA looks like this:
https://openqa.debian.net/tests/260723
- I adapted tasksel, to become an installer for Debian pure blends. The
new package is blendsel, see https://salsa.debian.org/holgerw/blendsel/
- I prepared a change in pkgsel, to call blendsel depending on the
descision, if Debian pure blends are wanted or not.
See https://salsa.debian.org/holgerw/pkgsel/
Anyway, I think I have it running so far, the blendsel dialog appears
and shows the items to select; I'm attaching a screenshot showing the current state (please note, that the dialog shows three desktop environments as placeholder for now; the tasksel - and therefore blendsel as well -
logic does not allow to have packages|tasks|blends listed that don't
have the corresponding task-* packages in the archive).
The template should be rephrased, I would ask for review on debian-l10n-english when the time comes, but I guess there is still
time for that...
Keeping the whole git history of tasksel without its tag is probably
fine, in case anyone needs to dig up why this thing is done that way,
but I'm not sure we should keep tasksel entries in debian/changelog; I
would probably only keep the blendsel entry, adding a reference to the version of tasksel it was forked off from. Unless some others feel
strongly we should keep the whole tasksel history in debian/changelog?
I've fixed a few minor things for the rename. It looks to me the README
could probably be stripped down to mention blendsel's being a fork of tasksel, and pointing at tasksel's README for more information. Less duplication would be best (and I'm not sure how current the contents are anyway). Ditto for tasks/README.
I think you know best how to adjust README.translators :)
I'm happy to upload it as-is (modulo debian/changelog), but I suspect
it'd make sense to adjust tasks/ before doing so? Happy either way.
- I prepared a change in pkgsel, to call blendsel depending on the
descision, if Debian pure blends are wanted or not.
See https://salsa.debian.org/holgerw/pkgsel/
That I didn't check yet, my focus is on the current blocker (as far as
the DM vs. DD limitation is concerned).
Anyway, I think I have it running so far, the blendsel dialog appears
and shows the items to select; I'm attaching a screenshot showing the current state (please note, that the dialog shows three desktop environments
as placeholder for now; the tasksel - and therefore blendsel as well - logic does not allow to have packages|tasks|blends listed that don't
have the corresponding task-* packages in the archive).
Understood, but please let me know if it makes sense to have them in the
0.1 upload, or if you'd like to introduce them in 0.2 once 0.1 has been accepted.
The template should be rephrased, I would ask for review on debian-l10n-english when the time comes, but I guess there is still
time for that...
You should talk to our beloved l10n coordinator!
And yeah, lintian/bookworm reports some things we don't normally do:
W: blendsel: using-first-person-in-templates blendsel/tasks [templates:16]
Seriously though, I'm not familiar with the semantics behind /first vs. /tasks in tasksel. Do we want/need the same semantics in blendsel?
I think we should have lintian-overrides for the main package, just like tasksel, at least for those (again, only running lintian/bookworm):
E: blendsel: no-debconf-config
W: blendsel: debconf-is-not-a-registry [usr/lib/blendsel/blendsel-debconf:3]
Finally, this should probably go away from both packages, I don't even remember having managed that package:
Conflicts: base-config (<< 2.32)
(And indeed, that was 20 years ago.)
Bonus points: maybe clean up tasksel's debian/source/lintian-overrides?
blendsel is now ready to be integrated into d-i, pkgsel and tasksel need an upload to make this happen.
What are your thoughts for this?
Do you want to make a first alpha/beta d-i release, as a "clean basis" without
this Blend integration approach?
Or am I allowed to upload now and we get a the blendsel solution in the first alpha/beta for Trixie?
If someone wants to give it a try, to see how it looks like:
I have a branch https://salsa.debian.org/holgerw/pkgsel-install-blendsel-unconditionally where blendsel is installed automatically together with tasksel, and blendsel's dialog appears automatically after the tasksel run has finished.
I would hope to have time to contribute some effort to helping make this happen in the near future, and am much more likely to get round to it if prodded, so please ask if there's anything I can help with.
I can see why you opted to put blendsel there from the point of view of
it being minimally invasive, but I think that after tasksel is too late
for blend selection.
Some blends may want to do things like preseed the desktop, or change >preferences for disk partitioning, or do other more radical things to
the way D-I works.
Debian-Edu's installer looks quite different at the tasksel stage for >instance:
https://openqa.debian.net/tests/320732#step/edu_profile/1
and the only thing before that in the Debian-Edu installer is locale >selection, so if we wanted to be able to offer Debian-Edu as a blend
we'd need to be asking about blends very early on, presumably
immediately after locale selection.
I would hope to have time to contribute some effort to helping make this >happen in the near future, and am much more likely to get round to it if >prodded, so please ask if there's anything I can help with.
In particular, I'll be happy to set up openqa tests for attempts to get >things working, and modify the existing tests so we can show that D-I
still works with this in place. I can also help you with getting
openqa-link setup, so that you can launch your own tests from salsa's CI.
Hi Phil,
Am 12. Dezember 2024 09:32:58 MEZ schrieb Philip Hands <phil@hands.com>:
I can see why you opted to put blendsel there from the point of view of
it being minimally invasive, but I think that after tasksel is too late
for blend selection.
Some blends may want to do things like preseed the desktop, or change >>preferences for disk partitioning, or do other more radical things to
the way D-I works.
Debian-Edu's installer looks quite different at the tasksel stage for >>instance:
https://openqa.debian.net/tests/320732#step/edu_profile/1
and the only thing before that in the Debian-Edu installer is locale >>selection, so if we wanted to be able to offer Debian-Edu as a blend
we'd need to be asking about blends very early on, presumably
immediately after locale selection.
I fear, what you describe here is not what was my goal, when I
started to work on this.
I acted on the approach, to modify tasksel so it can have a
hierachical structure for blends installation.
So, my path was to create a possibility, to install packages for
blends by selection. Not more.
What you describe above is a much more invasive approach, that
has effects in much more aspects of the installer.
I see two issues with this approach (at this time):
1.
I doubt I personally can perform such wide set of changings/functionality
2.
I'm unsure if it's the right time for such comprehensive changings
in this time of the Trixie development cycle.
That smells like more time needed for development and testing
to me?
I think I was perhaps forgetting that tasksel (and so blendsel) rely on
the installed system to do what they do, so one cannot push them earlier
in the order without more effort than I had in mind.
I still think it might be worth having an early question where it might
be possible to add more complexity later, just to provide a hook where
people like Debian-Edu could start developing things.
On the other hand, having a "Do you want to install a Blend?" question immediately after the locale selection seems a bit weird, and would be
rather annoying if answering it wrong would lead to blendsel not
appearing after tasksel, when one had hoped it would.
I guess some feedback from blends folk about what they're hoping for
would help at this point. Perhaps blendsel is just what most people had
in mind, in which case the likes of Debian-Edu just need to continue
with their custom D-I.
Philip Hands <phil@hands.com> (2024-12-12):
I think I was perhaps forgetting that tasksel (and so blendsel) rely on
the installed system to do what they do, so one cannot push them earlier
in the order without more effort than I had in mind.
I still think it might be worth having an early question where it might
be possible to add more complexity later, just to provide a hook where people like Debian-Edu could start developing things.
On the other hand, having a "Do you want to install a Blend?" question immediately after the locale selection seems a bit weird, and would be rather annoying if answering it wrong would lead to blendsel not
appearing after tasksel, when one had hoped it would.
I guess some feedback from blends folk about what they're hoping for
would help at this point. Perhaps blendsel is just what most people had
in mind, in which case the likes of Debian-Edu just need to continue
with their custom D-I.
As far as I can remember, at least Andreas was fine/happy with the idea proposed by Holger (which also matched what I had in mind to make some progress there), so I don't see why we should disrupt the install flow
with an early question for very specific usecases…
I confirm I was very happy about Holger's proposal and it might make
sense to keep things as simple as possible for the moment. My gut
feeling is that Debian Edu people consider their pre-seeding as a solved >problem. Since the request to offer some Blends selection inside the >installer did not came from Debian Edu its fine for them to stick to the >original proposal doing the Blends selection after tasksel. I could
imagine since the pre-seeding is done earlier its clear the user wants
Debian Edu (and no other Blend) so the Blends selection in this case
might be redundant and some option should be provided to skip blendsel.
Hi,
I know Debian Edu members are reading the debian-blends list but to
be very sure I put their list in CC.
Am Fri, Dec 13, 2024 at 02:11:00AM +0100 schrieb Cyril Brulebois:
Philip Hands <phil@hands.com> (2024-12-12):
I think I was perhaps forgetting that tasksel (and so blendsel) rely on
the installed system to do what they do, so one cannot push them earlier >> > in the order without more effort than I had in mind.
I still think it might be worth having an early question where it might
be possible to add more complexity later, just to provide a hook where
people like Debian-Edu could start developing things.
On the other hand, having a "Do you want to install a Blend?" question
immediately after the locale selection seems a bit weird, and would be
rather annoying if answering it wrong would lead to blendsel not
appearing after tasksel, when one had hoped it would.
I guess some feedback from blends folk about what they're hoping for
would help at this point. Perhaps blendsel is just what most people had
in mind, in which case the likes of Debian-Edu just need to continue
with their custom D-I.
As far as I can remember, at least Andreas was fine/happy with the idea
proposed by Holger (which also matched what I had in mind to make some
progress there), so I don't see why we should disrupt the install flow
with an early question for very specific usecases…
I confirm I was very happy about Holger's proposal and it might make
sense to keep things as simple as possible for the moment. My gut
feeling is that Debian Edu people consider their pre-seeding as a solved problem. Since the request to offer some Blends selection inside the installer did not came from Debian Edu its fine for them to stick to the original proposal doing the Blends selection after tasksel.
Hi all,
Am 13. Dezember 2024 08:29:21 MEZ schrieb Andreas Tille <tille@debian.org>:
I confirm I was very happy about Holger's proposal and it might make
sense to keep things as simple as possible for the moment. My gut
feeling is that Debian Edu people consider their pre-seeding as a solved
problem. Since the request to offer some Blends selection inside the
installer did not came from Debian Edu its fine for them to stick to the
original proposal doing the Blends selection after tasksel. I could
imagine since the pre-seeding is done earlier its clear the user wants
Debian Edu (and no other Blend) so the Blends selection in this case
might be redundant and some option should be provided to skip blendsel.
The idea is, that we add an entry to tasksel, which makes blendsel to
appear, if chosen.
So, if the Edu preseed file does not set this option, blendsel will
not be shown.
All good.
We now reached the point, where all this can be seen/tested in the wild aka via daily built images.
Please note, that the last relevant change did not reach testing yet, so you will have to install sid from a trixie daily build image, to test this.
The usual, good old tasksel dialog now has an additional entry at the bottom "Choose a Debian blend for installation" (this is not chosen by default) [blendsel_1.png].
If you choose this [blendsel_2.png], the blendsel dialog will appear after tasksel has done its work [blendsel_3.png].
So, the infrastructure is ready now, and I want to ask blend people for a list of blends, that you want to be included in this mechanism.
I already came across the list in <https://salsa.debian.org/blends-team/blends/-/blob/master/doc/en/04_existing_blends.xml?ref_type=heads>
Maybe that list could serve as template?
Please provide a list at your choice.
Also, if you would like to adapt the wording of the dialog, feel free to
tell me.
Also, if you would like to adapt the wording of the dialog, feel free to tell me.
Please spell Blend in
"Choose a Debian _b_lend for installation
with upper case _B_ (its a noun).
In the Blends selection I would start the actual selection (third image) with the
real Blend name like (and alphabetic ordering) and the "official" short description
(which each Blend in CC should answer)
Debian Astro
Debian Med (life sciences and medicine)
Debian Junior
Debian Science (various sciences)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 483 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 17:39:18 |
| Calls: | 9,617 |
| Calls today: | 3 |
| Files: | 13,692 |
| Messages: | 6,156,571 |