Hi, Michael Tokarev <[email protected]> (2025-06-07): > Hm. Why it replaces /bin/wget? It shouldn't replace already existing > files, I'd say, and this needs to be fixed. > > Yes, we've in d/rules: > dh_link -pbusybox-udeb \ > $$(grep -v sbin/init $b/udeb/busybox.links | sed 's|^|/bin/busybox > |') > > So, when things are installed, busybox-udeb is unpacked first, and > this creates /bin/wget symlink. And next wget-udeb is unpacked, > which replaces /bin/wget with real executable. Or does wget-udeb > installs to /usr/bin/wget? Shouldn't dpkg complain if there's a > file conflict?
Build log:
Preparing to unpack udebs/wget-udeb.udeb ...
Unpacking wget-udeb (1.25.0-2) ...
dpkg: warning: overriding problem because --force enabled:
dpkg: warning: trying to overwrite '/usr/bin/wget', which is also in
package busybox-udeb (1:1.37.0-4)
The --force seems to be dating back 20+ years:
https://salsa.debian.org/installer-team/debian-installer/-/commit/08dac4eff81a61421fe2f4358759c81ce2cf0ca8
Since I'm only seeing the override warning for wget (multiple times), at
least on amd64, it's tempting to remove the option and see whether daily
builds stay happy?
> > Oh, I don't think I've ever thought much about possible upgrades
> > there… Ouch.
>
> Most likely, yes. And it's been this way for years. I'm not sure
> now is the right time to fix this.
Just agreeing to remove wget from busybox is fine with me.
> Yes, plus the other WGET-related stuff has to be turned off too.
>
> I prepared this change, it's trivial to remove wget applet, but I'd
> love to understand how it all worked before.
Out of curiosity, what is “other WGET-related stuff”? I'm happy for you
to clean things up, as long as we don't break other things. :)
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
