Re: Next attempt to add Blends to Debian installer

2024-05-09 Thread Holger Wansing
Hi,

Holger Wansing  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?


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


Re: Next attempt to add Blends to Debian installer

2024-05-09 Thread Cyril Brulebois
Hallo Holger,

Holger Wansing  (2024-05-09):
> Holger Wansing  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?

That approach looks very fine to me, thanks.

> 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?

Looks good to me.

I totally understand how testing can be difficult until packages reach
the archive, feel free to “upload early, upload often”.

It looks like the 64-bit time_t transition is getting better (at least
from afar) but I don't have any immediate plans for a release at the
moment, so it's perfectly fine to have glitches/temporary regressions
following the introduction of this feature/new packages along the way.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature