Bug 1731704 - systemtap depends on files/directories from non-standard locations
Summary: systemtap depends on files/directories from non-standard locations
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemtap
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Frank Ch. Eigler
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1731683
TreeView+ depends on / blocked
 
Reported: 2019-07-21 11:11 UTC by Igor Raits
Modified: 2019-07-22 17:54 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-22 17:12:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Igor Raits 2019-07-21 11:11:23 UTC
Hello,

Fedora Packaging Guidelines allow dependencies only on files/directories from /usr/bin, /usr/sbin and /etc directories[0].
Your package depends on files/directories outside of those. See below for more information about package/dependencies.

---
systemtap-testsuite-4.2-0.20190618git47c3f6c60174.fc31.x86_64:
  - /usr/lib/libc.so
---

Please correct those or provide reason why is it correct.
It is very important to not download huge filelists.xml just because few packages in distribution depend on non-standard paths.

Thanks for cooperation!


[0] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_dependencies

Comment 1 Frank Ch. Eigler 2019-07-22 17:12:00 UTC
The systemtap testsuite subrpm is special in that it deliberately wants to request both 32- and 64-bit system libraries for testing.  Using the /usr/lib/libc.so seemed like the simplest way to accomplish part of this.  Since the -testsuite subrpm is of little to no interest to most users, I would not expect the filelists.xml download to hit hard.

Comment 2 Igor Raits 2019-07-22 17:12:55 UTC
FYI, downloading filelists.xml depends on full state of repo, not just if you install -testsuite.

Comment 3 Mark Wielaard 2019-07-22 17:54:01 UTC
Note that the underlying problem here is that x86-on-x86_64 multilib repositories aren't consistent.
On some systems you could simply Require glibc.i686 but on other systems (for example when building/running in kohi) you need glibc32.
So you end up with having to have a file/path based requirement because there is not clear package name to depend on.


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