25.10.2021 18:05, Ritesh Raj Sarraf wrote:
Hello Michael,
This change was proposed by the Dracut maintainers.
https://salsa.debian.org/linux-blocks-team/sg3-utils/-/merge_requests/1
While I don't use/test Dracut, I've always wanted to be willing to
accommodate more choice.
But now this is a challenge when integrating changes, where one doesn't
directly have an insight to all possible use cases/complications.
There's a simple question/answer for this. What exactly your package
_requires_ from - in this example - initramfs-tools-core? The key
word here is, ofc, "requires", ie, something providing by i-t-c which
is essential for functionality of your package.
There's a classic example of real requires: a shared library used by
an executable. You can't run your executable without that shared lib
being available. If that lib isn't installed, your package just fails
to work in any sensible way.
In your case, you might e.g. use some tool provided by initramfs-t-c
and throw error or fail to work if that tool isn't in use. Or, you
might require to do some work with your devices (like when assembling
cryptoloop or similar) to be done in initramfs before the system has
completed booting, or else you're unable to do something with these
devices. But even there it is still questionable - even in case of
cryptoloop this device can be created/used later for testing purposes,
not for booting the system, and the package should be able to work in
that case too without _requiring_ to be placed into initramfs.
On the other hand, some packages are useless without additional tools,
providing no value at all. Like a plugin (dynamically-loaded object)
for some application, - it can't be run directly so it does not throw
errors like when a shared library is missing, but the same fact that
it can't be run makes it absolutely useless by its own. In this case
it might be a good idea to _require_ the application in question, _or_
just to ignore this useless state, to be just like an orphaned shared
library.
Back to the package in question and this bugreport.
I don't know sg3-utils well enough, don't know what it is supposed
to do in all possible cases. But it seems it does not _need_ to be
in initramfs and does not directly use any tools from initfamfs package.
So I don't really see why it declares dependency on any initfamfs stuff
at all, be it dracut or anything. It puts an initramfs-tools droplet
into the right directory so when initfamfs-tools creates next initramfs
this package is taken into account, that's true, but this is not
*required* for the actual work, and other, alternative initramfs
schemes can be used too, and it is not even essential for sg3 stuff
to be in initramfs in the first place.
To me, the situation is like this: there's no actual need to declare
_any_ dependency on initramfs stuff at all, but if some "known"
initramfs stuff is installed this package can use it.
But maybe I overlooked something and it is actually required for sg3
to be there, or there's some more obscure integration scenario out
there, - I dunno.
For now, in order to fix this issue for our use (we have our own
initramfs and it ofcourse conflicts with initramfs-tools since they
both creates the same /boot/initrd.img-foo), I had to create another
fake/dummy package which provides initramfs-tools-core, just to
satisfy dependency of this sg3-utils-udev package. Which, in turn,
is required by multipath-tools which we use too (but not in initramfs).
It'd be nice to be able to use system without breaking boot or resorting
to these dirty tricks :)
Thanks!
/mjt
