Michael Tokarev <mjt@tls.msk.ru> (2022-05-08):
> The prob is not the burden of maintaining it, I'm okay with that one.
> It is just that the whole thing seems wrong :)
>
> Again, I'm definitely not arguing for dropping it right now, but we
> either plan to do this some other way, or we don't. If we do, we can
> start some discussion/review in this area.
If you want to double check every single place where preseeding can
happen, and prepare a plan to make this patch dispensable, feel free to.
It just seems to me that the cost of doing so is huge compared to the
gain over the current situation it would represent.
Personally, I'd rather spend my time on finally letting go of gtk2, for
example. (And that's because I have to, not because I want to.)
> The argument "it only affects the udeb" is lame :) Udeb does not need
> to suffer - neither this one nor any other udeb, and actually it does
> not only affect udeb, it affect busybox as a whole, and the upstream
> change which we revert is there for a reason :)
For the avoidance of doubt, that patch guards the “new” code with a
macro check, keeping the “old” code when an option is set. That option
is only set in the udeb build:
debian/config/pkg/deb:# CONFIG_FEATURE_DI_ENV_HACK is not set
debian/config/pkg/static:# CONFIG_FEATURE_DI_ENV_HACK is not set
debian/config/pkg/udeb:CONFIG_FEATURE_DI_ENV_HACK=y
so I'm not sure my argument is wrong in addition to being lame?
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature