debug package cannot have custom tags

[Jeff Johnson]

tracker

[Jan (jan-redhat-bugs)]

Description of problem:
Bug 447520 requires inclusion of the Obsoletes tag for the debug (debuginfo)
package. The current macros file(s) do not permit it.

Version-Release number of selected component (if applicable):
rpm-4.4.2.3-2.fc9.x86_64
redhat-rpm-config-9.0.2-1.fc9.noarch

How reproducible:
Always.

Steps to Reproduce:
1. Put into your .spec file: %define _debug_package_tags Obsoletes:
obsoleted-package
2. Patch /usr/lib/rpm/macros (and possibly /usr/lib/rpm/redhat/macros) by the
attached fix.
3. rpmbuild -bb *.spec
4. rpm -q --requires -p *-debuginfo.x86_64.rpm

Actual results:
(nothing)

Expected results:
obsoleted-package

Additional info:
This Bug will need to be cloned for redhat-rpm-config if approved.

[Jan (jan-redhat-bugs)]

Created attachment 306227
Insert new optional macro %{_debug_package_tags}.

[Jeff (jeff-redhat-bugs)]

FWIW, its likely easier process to manage if one implemented a different upgrade policy specifically
for -debuginfo packages, say, always obsoleting foo-debuginfo-V-R
when the foo-V-R is erased. That's likely 20-30 lines of C code in lib/depends.c, not hard at all.

Adding a macro expansion to permit (under packager control) an optionally
specified Obsoletes: when the package is built is sure to confuse packagers more than they already are
wrto building -debuginfo packages. JMHO, YMMV, as always.

[Jan (jan-redhat-bugs)]

I agree it is a crude hack and I expect most of the Obsoletes cases will forget
this debuginfo obsoletion.

Just I do not find it so clear how it should behave otherwise - there can be
multiple subpackages and even the basename package may not even exist (used for
example for F9 openoffice.org). You may obsolete just one of the subpackages.
And it is valid to have installed a debuginfo package without corresponding
matching binary package (for example for remote debugging; it is not perfectly
right as readonly code/data will not be available for the debugger in such case).

So if you have installed A, A-X and A-debuginfo, you install new package B which
obsoletes A and A-X you still cannot remove A-debuginfo as there may exist
package A-Y residing on a remote host which I want to use A-debuginfo for.

Which packages should get automatically removed/upgraded was discussed more in
the unfixed Bug 432806 and it may or may not fall into the YUM scope.

[Jeff (jeff-redhat-bugs)]

Heh, all of -debuginfo generation is a very crude hack that becomes increasingly obscure
and unmanageable.

Reading #432806 you appear to want any -debuginfo packages that are installed to
be maintained in sync with the set of executables in packages to which they are attached.

That's a perfectly reasonable goal imho.

And adding Obsoletes: to a package is the current mechanism by which package renaming is
discovered by depsolvers, so the mechanism to add an Obsoletes: to -debuginfo is perfectly
sound for the case of package renaming.

However, you already are pointing out (in 3rd paragraph of comment #3) that -debuginfo
can have different upgrade paths than other packages. Typically the Obsoletes: A in the new B
package is used by depsolvers to discover that B needs to be installed as the replacement for A,
in which case A-Y (in yr example) is typically obsoleted (and replaced by *some* new package
even if that is not by the new set of B packages) as part of renaming the original set A to B.

What is generally different about -debuginfo packages is that they are contextually dependent
on the existence of other installed packages (like the examples from the set {A,A-X,A-Y} you
have given).

The relation is typically many-to-one because there's a single -debuginfo generated
per build, even though there may be several sub-packages as in the set {A,A-X,A-Y}.

An identifier/marker for the set {A,A-X,A-Y} that is known in the -debuginfo package
is RPMTAG_SOURCERPM/RPMTAG_SOURCEPKGID (or even better add RPMTAG_SOURCEBUILDID
to all packages produced by a build}.

Once the members of the set {A,A-X,A-Y} and associated -debuginfo are known, then
a contextually sensitive policy rule for erasing -debuginfo is easily expressed:
    Remove the -debuginfo when the last installed member of the set {A,A-X,A-Y} is removed.

That policy rule handles the "out with the old" erasure portion of an upgrade as well, preserving
the older -debuginfo if {A,A-X} but not A-Y are replaced because there is still a member of
the set tied to the already installed -debuginfo.

Another policy rule for the "in with the new" install portion of an upgrade is also easily expressed:
    Install the new -debuginfo package when any member of the set {A-A-X,A-Y} is upgraded,
        AND
    the -debuginfo for the set was previously installed.

The odd corner case of having *only* the -debuginfo package installed for remote debugging
is unaffected by either of the two policy rules just mentioned because no member of the set
{A,A-X,A-Y} is installed, and so neither rule applies.

That's the "different upgrade policy" that I suggested in fuller detail.

Life with depsolvers like yum has 2 additional needs:

    1) adding Obsoletes for -debuginfo package renaming discovery (that's the patch in this bug).
    2) visibility of -debuginfo repositories, should -debuginfo repos be opt-in or opt-out? (that's
    my restatement of what I see in #432806).

I can code up the above upgrade policy for -debuginfo in rpm by generating a rpmdb index
for Sourcepkgid (buildid would be preferred but I haven't tried to add buildid to *.rpm
metadata yet), and mebbe 20-30 lines of logic in lib/depends.c r...

[Jan (jan-redhat-bugs)]

(In reply to comment #4)
> However, you already are pointing out (in 3rd paragraph of comment #3) that
> -debuginfo can have different upgrade paths than other packages. Typically
> the Obsoletes: A in the new B package is used by depsolvers to discover that
> B needs to be installed as the replacement for A,

More the Provides tag says that but sure it depends on how the upgrade happens.

> An identifier/marker for the set {A,A-X,A-Y} that is known in the -debuginfo
> package is RPMTAG_SOURCERPM/RPMTAG_SOURCEPKGID (or even better add
> RPMTAG_SOURCEBUILDID to all packages produced by a build}.

I did not find RPMTAG_SOURCEBUILDID anywhere. I expect it is unrelated to:
        http://fedoraproject.org/wiki/Releases/FeatureBuildId

> Once the members of the set {A,A-X,A-Y} and associated -debuginfo are known,

Therefore -debuginfo should contain the list of subpackages "A,A-X,A-Y"?
AFAIK currently there is no such information in -debuginfo rpm, right?

> then a contextually sensitive policy rule for erasing -debuginfo is easily
> expressed:
> Remove the -debuginfo when the last installed member of the set
{A,A-X,A-Y} is removed.

Yes, such rule would be great!

> Another policy rule for the "in with the new" install portion of an upgrade
> is also easily expressed:
> Install the new -debuginfo package when any member of the set {A-A-X,A-Y}
> is upgraded,
> AND
> the -debuginfo for the set was previously installed.

This is out of my rpm knowledge as automatic installation of packages is
a rpm5+ feature. I may pinpoint the current YUM flaw with kernel debuginfos:

If I have
  kernel-1.0
  kernel-debuginfo-1.0
  bash-1.0
and I do `yum update' it will say:
  Installing:
    kernel-2.0
  Upgrading:
    kernel-debuginfo-2.0
    bash-2.0
And I am left with kernel missing its debuginfo with the resulting packages:
  kernel-1.0
  kernel-2.0
  kernel-debuginfo-2.0
  bash-2.0

I would expect more the style:
  Installing:
    kernel-2.0
    kernel-debuginfo-2.0
  Upgrading:
    bash-2.0

> Life with depsolvers like yum has 2 additional needs:
>
> 1) adding Obsoletes for -debuginfo package renaming discovery (that's the
> patch in this bug).
> 2) visibility of -debuginfo repositories, should -debuginfo repos be
> opt-in or opt-out? (that's my restatement of what I see in #432806).

IMO either opt-out or automatic opt-in/out if any -debuginfo is installed.

> I can code up the above upgrade policy for -debuginfo in rpm by generating
> a rpmdb index for Sourcepkgid (buildid would be preferred but I haven't tried
> to add buildid to *.rpm metadata yet), and mebbe 20-30 lines of logic in
> lib/depends.c rpmtsAdd{Install,Erase}Element() if you are interested. I will
> likely do that @rpm5.org somewhen no matter what.

Sure I would like to get it fixed, debuginfos should get more important soon
(F10?) with the GCC debuginfo producer fixes by Alexandre Oliva.

Just rpm vs. rpm5 is not my war so I unfortunately have to live with YUM now.

[Jeff (jeff-redhat-bugs)]

FYI: rpm5 has abrbitrary tags. Any string identifier is mapped to a 1Gb tagno spce using a SHA-1.

But yes, RPMTAG_SOURCEBUILDID does not exist in rpom metadata yet. The tag will have exactly the
value that is described at the URI you gave. There's little reason not to carry the build id in
packages imho.

No -debuginfo shouldn't contain the names, but rather a set identifier/marker, that allows
the set of packages (including -debuginfo) to be enumerated and counted when necessary.
I'm currently using RPMTAG_SOURCERPM as a "build set" identifier, will move to RPMTAG_SOURCEPKGID
and/or RPMTAG_SOURCEBUILDID as my development progresses.

What is needed (no matter whether yum or rpm) is well defined behavior and expectations for
upgrading -debuginfo packages. I'm helping define that.

Are kernel-debuginfo packages reasonably sized these days? Last I checked,
duplicated symbol tables were leading to 500Mb kernel-debuginfo packages.
If kernel-debuginfo packages are now reasonably sized, I will attempt to also
address kernel-debuginfo issues. I suspect the erasure policy rule for -debuginfo I wrote
will Just Work, but there may be a few more details needed.

You will have to address yum issues through yum channels, all I can do is help identify the usage
case for Obsoletes: and perhaps clarify the issue of opt-in/opt-out visibility.

Meanwhile the -debuginfo package upgrade rules I outlined are certainly obvious and simple, and
perhaps 30% implemented @rpm5.org already. I expect to have a completed implementation this
weekend.

[Jeff (jeff-redhat-bugs)]

Automagic erasures of -debuginfo packages is now implemented @rpm5.org.
Thanks for your comments.

[Jeff (jeff-redhat-bugs)]

And most of the install rule to block old -debuginfo erasure until all other
packages with common *.src.rpm are erased is now also implemented.

I say "most" because (as I have implemented) there is an implicit
requirement that the attempted upgrade of the -debuginfo follows
the upgrade of all other packages that came from the same *.src.rpm.

Considering the other flaws (rewriting file paths in ELF headers in debugedit) that
are laready present, that is "gud enuf" for @rpm5.org development. I'll shuffle the
install/upgrade argv[] to ensure -debuginfo packages are last, or will split -debuginfo
into its own transaction set if necessary; both of those approaches are viable solutions.

[Bug (bug-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[devzero2000 (pinto-elia)]

Added in @rpm5.org rpm 5.2