Bug 2059858

Summary: .package_note-*.ld file clutters build directory, breaking Perl tests
Product: [Fedora] Fedora Reporter: Petr Pisar <ppisar>
Component: package-notesAssignee: Zbigniew Jędrzejewski-Szmek <zbyszek>
Status: CLOSED ERRATA QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 37CC: paul, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: package-notes-0.5-4.fc37 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-09-03 16:22:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2099999    
Bug Blocks:    

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.