Bug 2059858 - .package_note-*.ld file clutters build directory, breaking Perl tests
Summary: .package_note-*.ld file clutters build directory, breaking Perl tests
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: package-notes
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact:
URL:
Whiteboard:
Depends On: 2099999
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-03-02 08:10 UTC by Petr Pisar
Modified: 2022-09-05 14:00 UTC (History)
2 users (show)

Fixed In Version: package-notes-0.5-4.fc37
Clone Of:
Environment:
Last Closed: 2022-09-03 16:22:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 2043977 1 None None None 2022-03-28 11:55:24 UTC

Internal Links: 2062685

Description Petr Pisar 2022-03-02 08:10:22 UTC
Some Perl packages enumerate files in build directory as part of self tests. Examples are perl-Crypt-SMIME (bug #2059502), perl-Test-DistManifest (bug #2059504).

After deploying package notes into rpm-build (package-notes-srpm-macros-0.4-14.fc36.noarch), a .package_note-*.ld file is kept there and that breaks the tests. Example:

    #   Failed test 'No extra files that aren't in MANIFEST'
    #   at t/manifest.t line 29.
    # Not in MANIFEST: .package_note-perl-Crypt-SMIME-0.28-2.fc37.x86_64.ld
    # Looks like you failed 1 test of 1.

Would it be possible to remove that file before starting %check section automatically?

Comment 1 Paul Howarth 2022-03-02 10:20:52 UTC
Some other packages similarly affected:
 * perl-MouseX-SimpleConfig
 * perl-Scalar-Properties
 * perl-Software-License-CCpack
 * perl-Test-Assert
 * perl-Test-Mojibake
 * perl-Test-Signature
 * perl-Test-Synopsis

These packages all have existing workarounds to handle files left around from debuginfo generation. In the majority of cases these are pure-perl packages that contain no ELF objects and hence generate no debuginfo or package notes anyway; if the generation of these files could be suppressed for noarch packages, it would go a long way to avoiding the need for such workarounds.

Comment 2 Zbigniew Jędrzejewski-Szmek 2022-03-28 11:55:24 UTC
> Would it be possible to remove that file before starting %check section automatically?

So… it was added to %check as a work-around for other issues, see #2043977.
We could try to change the flags for %check to not refer to the note at all,
but I think it'd be hard to cover all cases. In particular many packages embed the notes
in %build in Makefiles and other generated config files, and then compile some
things in %check.

In general, I think the design should be that the notes file is created early and
available at all times, and is just used when appropriate, or not. This needs to be
managed by individual packages themselves, there's just too many combinations and
conflicting requirements to handle this centrally.

Sorry for not being able to do better. I think the best way to handle this is to
include the file in MANIFEST.SKIP.

> In the majority of cases these are pure-perl packages that contain no ELF objects and hence generate no debuginfo or package notes anyway; if the generation of these files could be suppressed for noarch packages, it would go a long way to avoiding the need for such workarounds.

This should already be the case. Since package-notes-0.4-14 the note is skipped
if %_target_cpu == noarch. But. It. Doesn't. Work. Just kill me.

%_target_cpu is set to x86_64 when %__spec_build_pre is invoked, but is set to
noarch when %build is invoked. I'll file a bug against rpm, let's see what they say.

Comment 3 Zbigniew Jędrzejewski-Szmek 2022-08-09 09:28:31 UTC
This should be fixed with the new approach in #2099999.

Comment 4 Ben Cotton 2022-08-09 13:41:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 5 Zbigniew Jędrzejewski-Szmek 2022-09-03 16:25:17 UTC
This should be fixed now with the new approach.

Comment 6 Petr Pisar 2022-09-05 14:00:23 UTC
Thanks. I confirm that noarch packages are not polluted anymore.


Note You need to log in before you can comment on or make changes to this bug.