For now I'm thinking of only requiring the profile sub-package on Tumbleweed. And when there's more platforms/distros available, I'd be happy to enhance how the requirement/provisioning is handled in the spec file.
I'm quoting your email here, for transparency's sake:
This looks somewhat like a band-aid fix? How do we usually handle
cases where we'd need "branding" packages? Thus, shouldn't this
require debuginfod-profile-openSUSE-Tumbleweed on tumbleweed
and the generic unbranded debuginfod-profile should only have
a template that's effectively disabling the service? I would expect
SUSE eventually wants to provide a server for SLES/ALP products as
well.
As-is the change to elfutils in tumbleweed is a no-op, so we don't need
to rush it?
Yes, it's a band-aid fix.
Usually we have something like this, for openSUSE branding packages:
Provides: %{name}-branding = %{version}
Conflicts: otherproviders(%{name}-branding)
Supplements: (%{name} and branding-openSUSE)
And something like this, for upstream branding packages:
Provides: %{name}-branding = %{version}
Conflicts: otherproviders(%{name}-branding)
Supplements: (%{name} and branding-upstream)
Well, I see there's hope to have debuginfod servers for other openSUSE/SUSE distros/products. So I think we can proceed with a standalone package that takes care of providing branding for openSUSE/SUSE instead, like NetworkManager-branding, and we could keep the debuginfo-branding-upstream in this package with the https://debuginfod.elfutils.org/ as URL for automatic federation, as seen in here.
In this case we'd have three branding packages: debuginfo-branding-upstream, debuginfo-branding-openSUSE and debuginfo-branding-SUSE. And their content can/should vary depending on the distro/product.
Now, for disabling this feature I think we could tweak /etc/profile.d/debuginfod.sh to check for a variable, e.g. NO_DEBUGINFOD_URLS, that would prevent /etc/profile from setting the DEBUGINFOD_URLS variable.
I'm sorry. I had to drop the priority of this one on my todo list. When I get back to this task I'm gonna weight the use of --enable-debuginfod-urls to pass URLs and the use branding packages.
For now I'm thinking of only requiring the profile sub-package on Tumbleweed. And when there's more platforms/distros available, I'd be happy to enhance how the requirement/provisioning is handled in the spec file.
Hi Richard,
I'm quoting your email here, for transparency's sake:
This looks somewhat like a band-aid fix? How do we usually handle cases where we'd need "branding" packages? Thus, shouldn't this require debuginfod-profile-openSUSE-Tumbleweed on tumbleweed and the generic unbranded debuginfod-profile should only have a template that's effectively disabling the service? I would expect SUSE eventually wants to provide a server for SLES/ALP products as well.
As-is the change to elfutils in tumbleweed is a no-op, so we don't need to rush it?
Yes, it's a band-aid fix.
Usually we have something like this, for openSUSE branding packages:
And something like this, for upstream branding packages:
Well, I see there's hope to have debuginfod servers for other openSUSE/SUSE distros/products. So I think we can proceed with a standalone package that takes care of providing branding for openSUSE/SUSE instead, like NetworkManager-branding, and we could keep the
debuginfo-branding-upstream
in this package with thehttps://debuginfod.elfutils.org/
as URL for automatic federation, as seen in here.In this case we'd have three branding packages:
debuginfo-branding-upstream
,debuginfo-branding-openSUSE
anddebuginfo-branding-SUSE
. And their content can/should vary depending on the distro/product.Now, for disabling this feature I think we could tweak
/etc/profile.d/debuginfod.sh
to check for a variable, e.g.NO_DEBUGINFOD_URLS
, that would prevent/etc/profile
from setting theDEBUGINFOD_URLS
variable.Thoughts are welcomed.
@marxin, @matz2, @rguenther: review reminder
I'm sorry. I had to drop the priority of this one on my todo list. When I get back to this task I'm gonna weight the use of
--enable-debuginfod-urls
to pass URLs and the use branding packages.