Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1071481 > unrolled thread

Bug#994492: sg3-utils-udev should not require initramfs-tools[-core]

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#994492: sg3-utils-udev should not require initramfs-tools[-core] Michael Tokarev <mjt@tls.msk.ru> - 2021-09-16 19:20 +0200
    Bug#994492: sg3-utils-udev should not require initramfs-tools[-core] Ritesh Raj Sarraf <rrs@debian.org> - 2021-10-25 17:10 +0200
      Bug#994492: sg3-utils-udev should not require initramfs-tools[-core] Michael Tokarev <mjt@tls.msk.ru> - 2021-11-02 08:10 +0100

#1071481 — Bug#994492: sg3-utils-udev should not require initramfs-tools[-core]

Package: sg3-utils-udev
Version: 1.45-1
Severity: minor

Starting bullseye, sg3-utils-udev requires (depends) on initramfs-tools[-core].
But it does not *use* any of the functionality of this package, except of
_extending_ initramfs-tools.

This dependency forces us to invent more and more dummy versions of
initramfs packages in order just to use core system functionality
(eg multipath-tools now depends on sg3-utils-udev which can not be
installed without initramfs-tools which breaks (replaces) our boot
infrastructure).

For now we installed an empty initramfs-tools-core-dummy package just
to be able to use multipath-tools and not break our systems.

Please note there's no mention of this new dependency in the changelog,
but it makes major issue for ones who does not use initramfs-tools.

Thank you!

[toc] | [next] | [standalone]

#1078029

[Multipart message — attachments visible in raw view] — view raw

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.

Michael: What do you propose a change for this ? I don't have any
preference here.


Thanks,
Ritesh

On Thu, 2021-09-16 at 20:13 +0300, Michael Tokarev wrote:
> Package: sg3-utils-udev
> Version: 1.45-1
> Severity: minor
> 
> Starting bullseye, sg3-utils-udev requires (depends) on initramfs-
> tools[-core].
> But it does not *use* any of the functionality of this package, except
> of
> _extending_ initramfs-tools.
> 
> This dependency forces us to invent more and more dummy versions of
> initramfs packages in order just to use core system functionality
> (eg multipath-tools now depends on sg3-utils-udev which can not be
> installed without initramfs-tools which breaks (replaces) our boot
> infrastructure).
> 
> For now we installed an empty initramfs-tools-core-dummy package just
> to be able to use multipath-tools and not break our systems.
> 
> Please note there's no mention of this new dependency in the changelog,
> but it makes major issue for ones who does not use initramfs-tools.
> 
> Thank you!

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

[toc] | [prev] | [next] | [standalone]

#1079080

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web