Petter Reinholdtsen <firstname.lastname@example.org> (2016-05-22): > [Cyril Brulebois] > > There's no udebs involved in what I summarized for Blends. > > Exactly. Thanks for confirming that your “Being able to add extra tasks using udebs is a feature, not a bug.” wasn't really on topic then. > I suspect using udebs to enable blends is be a better idea than > making the Blends tasksel tasks priority standard. Having this kind of move forced on us doesn't seem reasonable to me, which has been exactly my point over the past few mails. Let me reiterate: I don't want this to happen ever again. > > Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can > > certainly interact with it so that it behaves as desired. > > You misunderstand the role of the udebs. Please explain how you came to that conclusion. > The Debian Edu udeb ask for education-tasks to be installed, and > then the normal d-i take care of the rest to get the correct Debian > Edu tasks installed using tests and the locale settings. Sure, we > can come up with a new way to do it, but my point is that we are > using this feature of tasksel today, and there is no alternative I > know of that is equally robust and well integrated into the > installer. What? I'm talking about a future evolution. I can't see why something using a pre-pkgsel.d hook to prepare things for d-i couldn't be updated to create e.g. an extra file to get pkgsel to behave as intended. I don't see why such implementation details would be important in this discussion, and that's why I mentioned “debian-edu udebs can certainly interact with it so that it behaves as desired”. Pretty sure I'm not the one “misunderstanding” anything here. KiBi.
Description: Digital signature