(Christian: sorry for pinging you directly, but I need some longtimer wisdom for this touchy topic.) Hi, Ole Streicher <olebole@debian.org> (2016-05-17): > I don't see it problematic as it is in the moment: The list is not too > long: Even if it does not fit on one screen, the rest is visible with > just one scroll, and this is indicated by the scroollbar. And I don't > think that the number of options is too much (it shouldn't be much more, > however). Well, I suppose this is quite a reasonable thing for someone interested in having Debian Pure Blends in this menu to see it as non-problematic? I'd be interested in hearing what Christian thinks about it. What is presented to users has always been carefully weighed to make sure d-i is flexible yet not intimidating or confusion-generating. It looks to me we might be making a step in the wrong direction. While this is OK(-ish) for an alpha release, this seems like something that should be addressed before stretch is out. > > Also, not sure about the (lack of) ordering in Debian Pure Blends. > > The Debian desktop environment submenu might be considered a bit special > > (esp. after the default desktop changes…), but I don't see why the DPB > > one should be unsorted. (See attached tasksel-unsorted-greyscale.png) > > There is no specific order of the blends. One might think of some > structuring -- many blends are somehow science related, while others are > not --, but there is not much more to say about the internal structure. > And I have no idea how to get a better order even in this sense. In the > moment, they are alphabetically sorted, and this somehow reflects the > order they appear in the blends web page [1]. It also may help to find a > specific blend. Another idea would be to sort by popconn, but this is > not transparent to the end user. And, other than that, I see nothing > that would make list f.e. Debian Astro before or after DebiChem. Ah, they are kind-of alphabetically sorted, but "Hamradio" has no "Debian", then we have some variations depending on space between Debian and *, but not for DebianMultimedia, etc. My bad. > To improve that, two things have to be done: First, the tasksel > mechanism should allow ordered lists (in the moment, they are > automatically sorted as long as they have the same priority) -- please > open a bug report for this, if needed. Second, we need a good idea *how* > they should be actually ordered so that a specific blend can easily be > found. Do you have a proposal? This was just a minor point really, we can forget about this (see previous paragraph). > One problem here is the limited support of debconf for structures: there > is one (hackish) level of sections (eaten up by the "Debian Pure Blends" > section), but no folding or similar. Since this is discussed now over > years without anyone actually implementing an improvement here, I doubt > that that willbe changed before the next release, so we need something > that works in the current scheme (well, unless *you* volunteer to > implement this ;-) ). (If you think I'm not busy enough…) > And I also think that for an installer, there > should not be too much structure, since this makes the installation too > complicated. On the other hand, the current implementation is criticized > by some blends, f.e. NeuroDebian, who wishes a specific selection up to > the package level here. > > Do you have any proposals what should be changed? First things first: I don't think what NeuroDebian wants is going to happen within d-i, no. Not the place, and we have package managers for that. I have no idea whether the following is practical, and/or makes sense regarding d-i's logic, etc., but I'm wondering whether it would be possible to have checking "Debian Pure Blends" activate a follow-up screen which would list all Blends. This way, we would get the previous tasksel screen back, and only present the Blends to users who're actually asking for it. And that, without changing anything in debconf, its (non-)support for structure prompts, etc. Merging two tasks lists obtained in two stages shouldn't be too hard, I suppose. But does that make sense? Again, Christian is more knowledgeable in this area, and might have more insight. KiBi.
Attachment:
signature.asc
Description: Digital signature