Re: Let's talk about conflicts and omissions in the udeb distribution
On 12 October 2017 at 19:49, Cyril Brulebois <kibi@debian.org> wrote:
> Hi,
>
> Philipp Kern <pkern@debian.org> (2017-10-12):
>> On 2017-10-12 18:35, Dimitri John Ledkov wrote:
>> > Unpacking libkmod2-udeb (24-1) ...
>> > dpkg: warning: overriding problem because --force enabled:
>> > dpkg: warning: trying to overwrite '/sbin/depmod', which is also in
>> > package busybox-udeb 1:1.27.2-1
>> > dpkg: warning: overriding problem because --force enabled:
>> > dpkg: warning: trying to overwrite '/sbin/insmod', which is also in
>> > package busybox-udeb 1:1.27.2-1
>> > dpkg: warning: overriding problem because --force enabled:
>> > dpkg: warning: trying to overwrite '/sbin/lsmod', which is also in
>> > package busybox-udeb 1:1.27.2-1
>> > dpkg: warning: overriding problem because --force enabled:
>> > dpkg: warning: trying to overwrite '/sbin/modinfo', which is also in
>> > package busybox-udeb 1:1.27.2-1
>> > dpkg: warning: overriding problem because --force enabled:
>> > dpkg: warning: trying to overwrite '/sbin/modprobe', which is also in
>> > package busybox-udeb 1:1.27.2-1
>> > dpkg: warning: overriding problem because --force enabled:
>> > dpkg: warning: trying to overwrite '/sbin/rmmod', which is also in
>> > package busybox-udeb 1:1.27.2-1
>> >
>> > Do we need both implementations of modprobe tools? Should one of them
>> > (kmod, busybox) stop building/shipping them? Or should those tools be
>> > shipped in busybox-kmod-udeb and kmod-udeb?
>>
>> why is this on -devel and not -boot and why is this not in a bug?
>
Because this is a generic question of what should happen, for packages
and libraries that happened to be pulled into d-i.
As d-i team doesn't maintainer/recompile udebs independent of maintainers...
> Couldn't agree more.
>
>> https://bugs.debian.org/871045 is somewhat related.
>
> The kmod situation has been known for quite a while (see mklibs changes
> over the year). The bug above was opened by Aurélien so that we don't
> forget about possibly switching to using more busybox applets instead of
> fixing kmod. Feel free to file a bug report in the meanwhile though.
>
> This has been prompted by the recent interest of two kind developers who
> stepped up to maintain busybox.
>
>> > Ditto:
>> > Unpacking wget-udeb (1.19.1-4) ...
>> > dpkg: warning: overriding problem because --force enabled:
>> > dpkg: warning: trying to overwrite '/usr/bin/wget', which is also in
>> > package busybox-udeb 1:1.27.2-1
>
> AFAICT recent busybox's wget does HTTPS so we could think about dropping
> wget-udeb. Defaulting to busybox's wget right now means archs without
> wget's udeb (ISTR armel) still have wget (which wouldn't be the case
> anymore if we were to drop the wget applet from busybox).
>
>> > Also note that libkmod2-udeb does not actually ship libkmod.so.2... on
>> > that note this:
>> >
>> > INFO: Using /lib64/ld-linux-x86-64.so.2 as dynamic linker
>> > INFO: library reduction pass 1
>> > WARNING: Library libkmod.so.2 found in the default path
>> > /lib/x86_64-linux-gnu/
>> > WARNING: Library libslang.so.2 found in the default path
>> > /lib/x86_64-linux-gnu/
>> > WARNING: Library libnewt.so.0.52 found in the default path
>> > /usr/lib/x86_64-linux-gnu/
>> > WARNING: Library libgcc_s.so.1 found in the default path
>> > /lib/x86_64-linux-gnu/
>> > INFO: library reduction pass 2
>> > INFO: stripping and copying dynamic linker to
>> > ..//lib64/ld-linux-x86-64.so.2
>
> See first paragraph.
>
first paragraph is not that relevant at all. Imho it is a bug that
something in d-i is using a shared library that is not provided by any
.udeb and is instead borrowed from the build environment. Imho it
sounds extremely wrong that we inject linker, runtime, and shared
libraries from the host (chroot / debs) instead of using them from
udebs.
src:kmod ships bin:kmod bin:libkmod2 bin:libkmod2-udeb
bin:kmod & bin:libkmod2-udeb ship utils-only and although dependency
on libkmod2 is declared none of these utilities have a shared library
dependency on libkmod.so.2.
Imho libkmod2-udeb is missnamed. and should really be named kmod-udeb
-> as it only ships /bin/kmod and symlinks.
However, libkmod.so.2 is used by bin:udev-udeb from src:systemd
package. Currently it has a mkshlibs generated dependency on
libkmod2-udeb, when in fact libkmod2-udeb does not provide
libkmod.so.2. And instead it is taken from the environment of where
d-i was built.
The case for ./lib/ld-linux-x86-64.so.2 is even more interesting, as
libc6-udeb provides it, yet we use the one from the host system
instead, it seems.
I have no opinion about whether src:kmod or src:binutils should
provide modprobe et.al. But imho it should be done in a non-coflicting
way, such that we do not rely on unpack orderings to win conflicts.
>> > I've changed mklibs-copy to print a warning whenever libraries are
>> > pulled from the host instead of the udeb.
>> >
>> > Shouldn't the all of the above be shipped in udebs? As in do we expect
>> > .udebs to be selfcontained? I was a bit perplexed that libkmod2-udeb
>> > does not ship shared library and thus system one is used which is
>> > built differently.
>> > (all of udeb is build without hardening, but deb library is built with
>> > hardening)
>
> There's what you would expect, and current state of affairs. It's been
> worked on over the years (again, Aurélien has been working on this
> topic), but I think we'll still release a few versions that aren't
> prefect yet.
>
In general, is it expected in an ideal world
(policy/project/consensus-wise) for all shared libraries used by d-i
to be provided/shipped as udebs? As in are my current expectations
sane? It looked to me like this sort of stuff has been happening since
the dawn of time. And it is hard to tell if this is intentional, or
accidental / needs-work.
I am not sure why for example we compile .deb and .udeb of kmod for
example, when the contents of .debs are perfectly adequate to be used
in d-i environment (not talking about all other caveats as to why we
have udebs)
>> Maybe you should file bugs and/or discuss this on -boot.
>
> Of course, debian-boot@ is where d-i stuff happens; don't expect people
> to be subscribed to debian-devel@ (which can be dropped from further
> replies).
... but not all udebs are done by debian-boot@ people ;-)
ps. i guess i should sleep on this, and then filebugs and work towards
killing usage of mklibs-copy as redundant
--
Regards,
Dimitri.
Reply to: