Re: busybox upload and further maintenance
08.05.2022 23:06, Cyril Brulebois wrote:
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.
yeah, that's a long way forward, I know.
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.)
Yeah.
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?
Cyrill, I was nothing more than joking about the lame part, really.
Please note the smile.
As of the DI_ENV_HACK, I wondered what an interesting name it is,
which is being noticed if I forget to apply patches. And I stand
corrected, - indeed, you're absolutely right, this is something
specific to udeb due to this new config feature check. I haven't
noticed it when I initially looked at the patch (briefly).
Thank you for correcting me there!
/mjt
Reply to: