Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation).
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages: - less entries in the dependency graph - removal of illogical dependency - less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages: - stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
Zbyszek
On Sun, Apr 28, 2019 at 4:57 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation).
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
I've worked in distributions that have implemented this policy, and it's often much more frustrating to work with because of it. It's not always obvious that pkgconfig missing is the reason why stuff doesn't build or otherwise work correctly.
I'm pretty sure the reason for having the auto-generated requirement on pkg-config was to make it easy and obvious to use stuff through pkgconfig.
I'm personally not in favor of doing this. I know that recently there has been this kick to shrink the default buildroot and minimize the dependency chain in extreme ways. I'm fairly certain a chunk of this has to do with RHEL modularity, but there's also the obvious bit of speeding up buildroot construction.
But to be honest, this isn't a significant drain on the dep chain (if we still had the other pkgconfig implementation, it might be, since that pulled in glib2 in the minimal tree).
If the problem is pkgconf-m4, I could be persuaded to drop pkgconf-pkg-config's requirement on it. I kept it there principally because the old pkgconfig package had the m4 file in there too.
The impact is minimal, it's a developer-side dependency anyway, and it's often useful to have. So from my point of view, I don't see a problem with it. And the dependency generator already makes it "/usr/bin/pkg-config", so you could theoretically swap it with any other conforming implementation.
In the end, I don't see any reasonable benefit for doing this, and it just makes developer and packaging work more frustrating.
Also, w.r.t. so files, we _do_ pull in the linker library. The library "ld-linux-$ARCH.so.$SOMAJOR" is always pulled in by every rpm containing a library.
On Sun, Apr 28, 2019 at 11:34 PM Neal Gompa ngompa13@gmail.com wrote:
On Sun, Apr 28, 2019 at 4:57 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation).
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
libpkgconf)
(Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
I've worked in distributions that have implemented this policy, and it's often much more frustrating to work with because of it. It's not always obvious that pkgconfig missing is the reason why stuff doesn't build or otherwise work correctly.
I'm pretty sure the reason for having the auto-generated requirement on pkg-config was to make it easy and obvious to use stuff through pkgconfig.
I'm personally not in favor of doing this. I know that recently there has been this kick to shrink the default buildroot and minimize the dependency chain in extreme ways. I'm fairly certain a chunk of this has to do with RHEL modularity, but there's also the obvious bit of speeding up buildroot construction.
I hope you are not talking about my Change Proposal because it has nothing to do with Modularity and/or RHEL :)
But to be honest, this isn't a significant drain on the dep chain (if
we still had the other pkgconfig implementation, it might be, since that pulled in glib2 in the minimal tree).
If the problem is pkgconf-m4, I could be persuaded to drop pkgconf-pkg-config's requirement on it. I kept it there principally because the old pkgconfig package had the m4 file in there too.
I think I would start first dropping make from buildroot.
The impact is minimal, it's a developer-side dependency anyway, and it's often useful to have. So from my point of view, I don't see a problem with it. And the dependency generator already makes it "/usr/bin/pkg-config", so you could theoretically swap it with any other conforming implementation.
In the end, I don't see any reasonable benefit for doing this, and it just makes developer and packaging work more frustrating.
Also, w.r.t. so files, we _do_ pull in the linker library. The library "ld-linux-$ARCH.so.$SOMAJOR" is always pulled in by every rpm containing a library.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sun, Apr 28, 2019 at 11:04 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation).
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
It would be nice to have something like Requires: (pkg-config if pkgconfig(*)) which would install pkgconf if any packages providing pkgconfig(…) are installed.. But I'm afraid we can't do that now.
Zbyszek
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbyszek@in.waw.pl) wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, which is currently owned by pkgconf-pkg-config, no?
Lennart
-- Lennart Poettering, Berlin
On Mon, Apr 29, 2019 at 5:04 AM Lennart Poettering mzerqung@0pointer.de wrote:
On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbyszek@in.waw.pl) wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, which is currently owned by pkgconf-pkg-config, no?
Correct. pkgconf-pkg-config owns all the base paths for pkgconfig content.
On Mon, Apr 29, 2019 at 06:29:06AM -0400, Neal Gompa wrote:
On Mon, Apr 29, 2019 at 5:04 AM Lennart Poettering mzerqung@0pointer.de wrote:
On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbyszek@in.waw.pl) wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, which is currently owned by pkgconf-pkg-config, no?
Correct. pkgconf-pkg-config owns all the base paths for pkgconfig content.
Or simply co-own the directory from all packages that put files there. Systemd does this already, and explicitly skips the dependency on pkg-config.
Zbyszek
On Mon, Apr 29, 2019 at 8:05 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Apr 29, 2019 at 06:29:06AM -0400, Neal Gompa wrote:
On Mon, Apr 29, 2019 at 5:04 AM Lennart Poettering mzerqung@0pointer.de wrote:
On So, 28.04.19 20:55, Zbigniew Jędrzejewski-Szmek (zbyszek@in.waw.pl) wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
You probably need some base RPM to own the dir /usr/lib64/pkgconfig then, which is currently owned by pkgconf-pkg-config, no?
Correct. pkgconf-pkg-config owns all the base paths for pkgconfig content.
Or simply co-own the directory from all packages that put files there. Systemd does this already, and explicitly skips the dependency on pkg-config.
It does this specifically because a pc file is shipped in the main package. That's a pretty rare circumstance.
Zbigniew Jędrzejewski-Szmek wrote:
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Now, if the proposal includes offering to help do a some/most of the work to fix all these, then I withdraw the objection.
-- Rex
On Mon, Apr 29, 2019 at 02:00:41PM -0500, Rex Dieter wrote:
Zbigniew Jędrzejewski-Szmek wrote:
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Now, if the proposal includes offering to help do a some/most of the work to fix all these, then I withdraw the objection.
Obviously. I would do most of the work myself.
Zbyszek
On Mon, Apr 29, 2019 at 3:20 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Apr 29, 2019 at 02:00:41PM -0500, Rex Dieter wrote:
Zbigniew Jędrzejewski-Szmek wrote:
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Now, if the proposal includes offering to help do a some/most of the work to fix all these, then I withdraw the objection.
Obviously. I would do most of the work myself.
I'm not convinced that this is worth it. There's nothing appreciably saved by doing this, and it creates an annoying inconvenience for people who are trying to package software in Fedora.
You're spending a ton of effort for 200KB that will have outsized negative impact on the ecosystem by making it non-intuitively harder to package and use software.
Beyond "removal of illogical dependency", which frankly only applies to how systemd is packaged, why do you want to do this? This doesn't save us an unwanted dep like the GCC removal does. This doesn't remove a massive buildroot dependency like the GDB one does. If you want the pkgconf-m4 package to not be auto-installed with pkgconf-pkg-config, I'm happy to make that change.
But past that? What does anyone get from this? Basically nothing.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Apr 29, 2019 at 9:20 PM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Mon, Apr 29, 2019 at 02:00:41PM -0500, Rex Dieter wrote:
Zbigniew Jędrzejewski-Szmek wrote:
Proposal: let's drop the autogenerated dependency on
/usr/bin/pkg-config
(this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Now, if the proposal includes offering to help do a some/most of the
work to
fix all these, then I withdraw the objection.
Obviously. I would do most of the work myself.
I think it would make sense to avoid the autogenerated dep just for the directory ownership. It's a fairly tedious thing to change though: update %files lists for each package that ships .pc files, update build requires for packages that now need to list BuildRequires: pkg-config, update the rpm dep generator. And then after all of that is done, verify that things still build, now that the autogenerated dep is gone from everything in the build root. It's a lot of changes to make, but if you want to go through the pain of doing all of that then I don't mind :)
Also, what should the BR be? BuildRequires: /usr/bin/pkg-config BuildRequires: pkg-config BuildRequires: pkgconfig BuildRequires: pkgconf BuildRequires: pkgconf-pkg-config
Kalev
On Tue, Apr 30, 2019 at 12:38 PM Kalev Lember kalevlember@gmail.com wrote:
On Mon, Apr 29, 2019 at 9:20 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Apr 29, 2019 at 02:00:41PM -0500, Rex Dieter wrote:
Zbigniew Jędrzejewski-Szmek wrote:
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config,
libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Now, if the proposal includes offering to help do a some/most of the work to fix all these, then I withdraw the objection.
Obviously. I would do most of the work myself.
I think it would make sense to avoid the autogenerated dep just for the directory ownership. It's a fairly tedious thing to change though: update %files lists for each package that ships .pc files, update build requires for packages that now need to list BuildRequires: pkg-config, update the rpm dep generator. And then after all of that is done, verify that things still build, now that the autogenerated dep is gone from everything in the build root. It's a lot of changes to make, but if you want to go through the pain of doing all of that then I don't mind :)
Also, what should the BR be? BuildRequires: /usr/bin/pkg-config BuildRequires: pkg-config BuildRequires: pkgconfig BuildRequires: pkgconf BuildRequires: pkgconf-pkg-config
If we're going to go down this road, it should be
BuildRequires: /usr/bin/pkg-config
That's what's required for the dep generator to work, too.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, 30 Apr 2019 at 18:19, Neal Gompa ngompa13@gmail.com wrote: [..]
If we're going to go down this road, it should be
BuildRequires: /usr/bin/pkg-config
That's what's required for the dep generator to work, too.
And what is wrong with just "BuildRequires: pkgconfig"? Don't you see that this forces dependencies resolution to use packages files list? IIRC Fedora already had policy to not use paths in BRs.
[tkloczko@domek SPECS]$ rpm -qf /usr/bin/pkg-config pkgconf-pkg-config-1.6.1-1.fc31.x86_64 [tkloczko@domek SPECS]$ rpm -q --whatprovides pkgconfig pkgconf-pkg-config-1.6.1-1.fc31.x86_64
kloczek
On Tue, Apr 30, 2019 at 3:49 PM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On Tue, 30 Apr 2019 at 18:19, Neal Gompa ngompa13@gmail.com wrote: [..]
If we're going to go down this road, it should be
BuildRequires: /usr/bin/pkg-config
That's what's required for the dep generator to work, too.
And what is wrong with just "BuildRequires: pkgconfig"?
That is no guarantee that '/usr/bin/pkg-config' will be provided, which is required by the dep generator and various tools.
Don't you see that this forces dependencies resolution to use packages files list?
This is free already, as that data is always part of the solver cache.
Besides, there is no ban on paths that are provided by primary.xml (*/bin, */sbin, */lib(64|exec), /etc). The ban is basically pointless, but that's what it is.
IIRC Fedora already had policy to not use paths in BRs.
Outside of paths already provided in primary.xml, packagers SHOULD NOT, yes.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Tue, 30 Apr 2019 at 21:04, Neal Gompa ngompa13@gmail.com wrote:
And what is wrong with just "BuildRequires: pkgconfig"?
That is no guarantee that '/usr/bin/pkg-config' will be provided, which is required by the dep generator and various tools.
You just put in my hand +1 to not use paths in BuildRequires. +1 for me. Thx. If you will look across /usr/lib/macros and files in /usr/lib/rpm/macros.d you will find hundreds of other commands used with full path and only occasionally some of them are used in BRs in form "BuildRequires: /some/path/command". Are going to request/propose to change whole distribution pattern of BRs? Really? FYI: We call that thing which you are refusing to use .. abstraction.
Don't you see that this forces dependencies resolution to use packages
files list?
This is free already, as that data is always part of the solver cache.
Besides, there is no ban on paths that are provided by primary.xml (*/bin, */sbin, */lib(64|exec), /etc). The ban is basically pointless, but that's what it is.
<counerargument=WRONG> rpmbuild is not using dnf xml files :-/ </counerargument>
IIRC Fedora already had policy to not use paths in BRs.
Outside of paths already provided in primary.xml, packagers SHOULD NOT, yes.
You are again talking about *install package time dependencies resolution*. Command rpmbuild which is processing spec files is using *rpm database*. We are talking about packages *build time dependencies resolution*. Please do me a favourite and execute on your system from root "rpm --rebuilddb; ls -l /var/lib/rpm/{Basenames,Providename}" and answer on the question: query to which one rpm table has chance to be shorter?
kloczek
On Tue, Apr 30, 2019 at 6:42 PM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On Tue, 30 Apr 2019 at 21:04, Neal Gompa ngompa13@gmail.com wrote:
And what is wrong with just "BuildRequires: pkgconfig"?
That is no guarantee that '/usr/bin/pkg-config' will be provided, which is required by the dep generator and various tools.
You just put in my hand +1 to not use paths in BuildRequires. +1 for me. Thx. If you will look across /usr/lib/macros and files in /usr/lib/rpm/macros.d you will find hundreds of other commands used with full path and only occasionally some of them are used in BRs in form "BuildRequires: /some/path/command". Are going to request/propose to change whole distribution pattern of BRs? Really? FYI: We call that thing which you are refusing to use .. abstraction.
No I didn't. I know perfectly well what abstractions are, and you're asking me to remove an abstraction, not add one.
And no, I'm not going to request that. However, that's what we have *now* and that abstraction (yes, it is one!) allows any valid provider of /usr/bin/pkg-config to step in and satisfy the role for the dependency generator. That's how *I* swapped pkgconfig for pkgconf back in Fedora 26. Trust me, I know how this works.
Don't you see that this forces dependencies resolution to use packages files list?
This is free already, as that data is always part of the solver cache.
Besides, there is no ban on paths that are provided by primary.xml (*/bin, */sbin, */lib(64|exec), /etc). The ban is basically pointless, but that's what it is.
<counerargument=WRONG> rpmbuild is not using dnf xml files :-/
</counerargument>
Yes, but "dnf builddep" does... which we use as part of constructing a package build environment.
IIRC Fedora already had policy to not use paths in BRs.
Outside of paths already provided in primary.xml, packagers SHOULD NOT, yes.
You are again talking about install package time dependencies resolution. Command rpmbuild which is processing spec files is using rpm database. We are talking about packages build time dependencies resolution.
Are you seriously being obtuse on purpose?
But you seem to be missing the point. We use the BuildRequires listed in the spec to install build dependencies using DNF with Mock. That's how build environments are populated. All build-time dependencies are install-time dependencies when you're preparing to build a package. I don't know how you missed *that*.
Please do me a favourite and execute on your system from root "rpm --rebuilddb; ls -l /var/lib/rpm/{Basenames,Providename}" and answer on the question: query to which one rpm table has chance to be shorter?
Just stop. Please.
First: the phrase is "do me a favor", not "do me a favo[u]rite".
Second, do you not even know that Mock passes --nodeps to rpmbuild because the rpmdb in the chroot isn't necessarily compatible with rpm in the chroot? We currently don't allow rpmbuild to evaluate dependencies at all. We may change this if Koji switches to producing bootstrap chroots before producing the build chroot. So right now, that lookup is not even happening.
Third, if the lookup is happening, rpmbuild is perfectly capable of evaluating file deps effectively. The rpmdb is relatively efficient for this kind of lookup.
On Wed, 1 May 2019 at 03:24, Neal Gompa ngompa13@gmail.com wrote: [..]
Second, do you not even know that Mock passes --nodeps to rpmbuild because the rpmdb in the chroot isn't necessarily compatible with rpm in the chroot? We currently don't allow rpmbuild to evaluate dependencies at all. We may change this if Koji switches to producing bootstrap chroots before producing the build chroot. So right now, that lookup is not even happening.
Calling rpmbuild with --nodeps to be able to resolve build dependencies from outside chroot and duplicating resolution of those dependencies by adding more code in yum/dnf to handle situation when rpm database in chroot is in different version is really .. "interesting".
Just checked all Fedora spec files to find few of them which are using straight rpm command in %build or %check. One of those specs is elfutils.spec in which is:
%check # Record some build root versions in build.log uname -r; rpm -q glibc
In https://kojipkgs.fedoraproject.org//packages/elfutils/0.176/2.fc31/data/logs... is possible to find:
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.F4TimI + umask 022 + cd /builddir/build/BUILD + cd elfutils-0.176 + uname -r 5.0.6-200.fc29.x86_64 + rpm -q glibc glibc-2.29.9000-17.fc31.x86_64
I'm really happy that rpm database still is available inside mock chroot (ufff).
During +25 years of using rpm it was at least two times situation when rpm was in kind of transition and in all those cases to build packages using my own automation I was always able to use just chroot command, and to be honest I would never even think about use "that way".
If not using simplest "BuildRequires: pkgconfig" may be (somehow) affected by above (which I'm 100% sure that it is still not the case because still above isn't by any way kind of counterargument against "BuildRequires: pkgconfig") .. I think that I'll give up.
kloczek
Le mercredi 01 mai 2019 à 08:18 +0100, Tomasz Kłoczko a écrit :
On Wed, 1 May 2019 at 03:24, Neal Gompa ngompa13@gmail.com wrote: [..]
Just checked all Fedora spec files to find few of them which are using straight rpm command in %build or %check. One of those specs is elfutils.spec in which is:
%check # Record some build root versions in build.log uname -r; rpm -q glibc
Funny; that’s pretty much https://github.com/rpm-software-management/rpm/issues/607
that upstream does not want to acknowledge.
Regards,
On Wed, 1 May 2019 at 09:04, Nicolas Mailhot nicolas.mailhot@laposte.net wrote: [..]
One of those specs is elfutils.spec in which is:
%check # Record some build root versions in build.log uname -r; rpm -q glibc
Funny; that’s pretty much https://github.com/rpm-software-management/rpm/issues/607
that upstream does not want to acknowledge.
IMO maintainer in this case is 100% right because all properties of the build env already can be described in with enough precision. Providing more details about build env will be duplicating current build dependencies.
Discussion about such cases should start from analyse of some case(s) when such details could help with some class of issues. Then someone should go to root cause that some exact failed/produced broken packages, and then (maybe) at the end some solution can be provided. All those context details are missing in that issue ticket so (IMO) rpm maintainer had no even chance understand what caused that someone started thinking about storing such metadata in src.rpm.
BTW elfutils and glibc package EVR. This detail is already part of the koji root.log. https://kojipkgs.fedoraproject.org//packages/elfutils/0.176/2.fc31/data/logs... contains line:
DEBUG util.py:556: glibc x86_64 2.29.9000-17.fc31 build 3.9 M
Nevertheless some people forgets sometimes that spec syntax provides not only BuildRequire but BuildConflict token as well. With those two is possible with 100% accuracy describe build env properties. That is all what rpmbuild needs to provide (IMO).
[tkloczko@domek SPECS.fedora]$ grep ^BuildConflict * | wc -l 38
Some packages source code build automation implements sometimes strange things. For example gawk is using libsigsegv only if autoconf is able to find it, and it is not possible to disable using it by provide configure parameter. However there is only handful of such cases and it is easier to fix those packages source code build automation than designing rpm extensions to handle such cases straight on packaging layer.
Uniformity below packaging layer should be our real goal .. this why when I see that in git repos someone is using some strange tagging convention like replace dots by underscores or putting build automation deep below project root directory (examples: recently introduced meson and cmake files in lz4 and zstd) I'm always trying gently ask maintainers to change this to implement and use those bits in kind of StandardWay(tm). All because it makes packaging easier with virtually no costs on layer below.
Other issue is that as Fedora keeps only last versions/releases of all packages and even if someone would be storing full list of all installed packages in build env in koji gut it will have very limited abilities to help with something as it is not possible quickly reassembly from scratch exactly the same build env out of the available packages.
So question which only left from this branch of the discussion is: What was the exact initial impulse which pushed someone to idea of storing full build env properties in src.rpm? IMO someone have been only thinking that this could solve something (that someone had only incorrect impression that it would help with something).
kloczek
Le mercredi 01 mai 2019 à 13:12 +0100, Tomasz Kłoczko a écrit :
On Wed, 1 May 2019 at 09:04, Nicolas Mailhot < nicolas.mailhot@laposte.net> wrote: [..]
One of those specs is elfutils.spec in which is:
%check # Record some build root versions in build.log uname -r; rpm -q glibc
Funny; that’s pretty much https://github.com/rpm-software-management/rpm/issues/607
that upstream does not want to acknowledge.
IMO maintainer in this case is 100% right because all properties of the build env already can be described in with enough precision. Providing more details about build env will be duplicating current build dependencies.
You're confusing constrains (build dependencies) with actual build env composition (exact constrains resolution, which has been known to change even with the same package set, just by switching dependency resolution engines from yum to dnf to whatever).
Build env composition information is generally useful for audits, reproducibility, and debugging. It's useful enough to have been reimplemented over the years in multiple places (elfutils spec, koji, whatever). It's even more useful with the recent tendency to static build.
What is missing is a mecanism to record in in a generic way package- side, so one does not have to rely on build farm logs (that may or may not be retained over time) to access this basic info.
Computing this info is trivial. It’s just a rpm -qa at the end of buildrequires resolution. Accessing this info reliably, however, it not trivial today, because the storage part has not been streamlined.
On Thu, 2 May 2019 at 20:29, Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote: [..]
IMO maintainer in this case is 100% right because all properties of the build env already can be described in with enough precision. Providing more details about build env will be duplicating current build dependencies.
You're confusing constrains (build dependencies) with actual build env composition (exact constrains resolution, which has been known to change even with the same package set, just by switching dependency resolution engines from yum to dnf to whatever).
Build env composition information is generally useful for audits, reproducibility, and debugging. It's useful enough to have been reimplemented over the years in multiple places (elfutils spec, koji, whatever). It's even more useful with the recent tendency to static build.
What is missing is a mecanism to record in in a generic way package- side, so one does not have to rely on build farm logs (that may or may not be retained over time) to access this basic info.
Computing this info is trivial. It’s just a rpm -qa at the end of buildrequires resolution. Accessing this info reliably, however, it not trivial today, because the storage part has not been streamlined.
As I wrote problem only is that without possibility really rollback to the full state described in set of exact N-E:V-Rs packages recorded data such auditing data in case if something starts going wrong such data could be used only as kind of murky vector where possible cause really is. It is nothing wrong with keeping only latest versions of the packages but with that assumption to have enough effectiveness of catching errors/issues needs to be added more test units fired straight after package build is done or during that process. Just look on some numbers below:
[tkloczko@domek SPECS.fedora]$ grep ^%check *| wc -l; ls -1| wc -l 11692 21300
and the same stats on results of my own work:
[tkloczko@domek SPECS.g2v]$ grep ^%check *| wc -l; ls -1| wc -l 426 498
Do you see where my thoughts are heading? With that only in last 3-4 months I've been able to catch maybe even few tenths of new issues just right on build packages (you can check stat of my accounts on gitlab and github to be able spot that part of my activity). I fully understand why Fedora keeps only latest versions of the packages and it is nothing wrong with that. Problems only is that if that small bit must be kind of assumption other parts around needs to be readjusted to create kind of strategy catching and dealing with new issues. And again .. with assumption that during packages development process never would be possible to fully rollback to the same N-E:V-Rs state storing build time metadata is kind of pointless (IMO). In other words reproducibility of those N-E:V-Rs metadata in case of Fedora are very close to *null*.
BTW: storing all N-E:V-Rs of the *packages* could be easily solved by move away from rpm to IPS and I know that in case of the Fedora that kind of change is unrealistic. Adapting rpm to use packages repository like it is in case of IPS is unrealistic as well .. because to many things around needs to be changed (not only on packaging and distribution layer). You can observe this kind of effect on for example Sol 11.4 packages http://pkg.oracle.com/solaris/release/en/ The same web interface which immanent part of the IPS provides very long list of all version of the packages if you would be able to observe all Solaris SRUs (Service Recommended Updates) data. On Solaris 10 with IPS is possible even rollback to the state ~10 years old. Full rollback to the system state of all packages from the past is sometimes really important and this is why in OL repositories are never deleted older packages (yum/dnf repo allows keep multiple E:VRs of the same package in single repository).
kloczek
On Fri, 3 May 2019 at 09:46, Tomasz Kłoczko kloczko.tomasz@gmail.com wrote: [..]
URL correction: http://pkg.oracle.com/solaris/release/
kloczek
Le vendredi 03 mai 2019 à 09:46 +0100, Tomasz Kłoczko a écrit :
ial today, because the storage part has not been streamlined.
As I wrote problem only is that without possibility really rollback to the full state described in set of exact N-E:V-Rs packages recorded data such auditing data in case if something starts going wrong such data could be used only as kind of murky vector where possible cause really is.
There's nothing murky or wrong in beiang able to answer "which static builds have used this rotten package" without needing to contact a centralised system like koji or IPS.
You're assuming the only use is roolback. It's not
On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote: [..]
You're assuming the only use is roolback. It's not
Point taken. Can you shortly describe other use cases?
kloczek
Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit :
On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote: [..]
You're assuming the only use is roolback. It's not
Point taken. Can you shortly describe other use cases?
You use apps in one of those languages that static build by default. There is a security alert in one code component. You want to know which packages in your repo/mirror have been build using the broken piece of source code
On Fri, 3 May 2019 at 12:44, Nicolas Mailhot nicolas.mailhot@gmail.com wrote: [..]
Point taken. Can you shortly describe other use cases?
You use apps in one of those languages that static build by default. There is a security alert in one code component. You want to know which packages in your repo/mirror have been build using the broken piece of source code
OK. Some time ago I've successfully removed all static libraries on my all build systems. Good to know that I will never have such dilemmas :o)
Do you have maybe other examples of the use cases? :p
kloczek
On Fri, May 3, 2019 at 8:26 AM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On Fri, 3 May 2019 at 12:44, Nicolas Mailhot nicolas.mailhot@gmail.com wrote: [..]
Point taken. Can you shortly describe other use cases?
You use apps in one of those languages that static build by default. There is a security alert in one code component. You want to know which packages in your repo/mirror have been build using the broken piece of source code
OK. Some time ago I've successfully removed all static libraries on my all build systems. Good to know that I will never have such dilemmas :o)
Nope. Between Go and Rust, you have literally thousands of static linked dependencies, so it does matter in that case.
On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote:
Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit :
On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote: [..]
You're assuming the only use is roolback. It's not
Point taken. Can you shortly describe other use cases?
You use apps in one of those languages that static build by default. There is a security alert in one code component. You want to know which packages in your repo/mirror have been build using the broken piece of source code
Last time we disagreed on this topic my opinion was that static linking should imply bundled provides:
Provides: bundled(<as usual>) = <crate or module version>
Hopefully something that could be automated for some stacks. To me there is no difference between bundling source code and bundling arch code, since most of the time I have seen it in action it was more a feat of vendoring for internal usage rather than actually providing a duplicate something to be consumed by others. And it would solve the post-CVE system inspection problem.
Dridi
Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit :
On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote:
Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit :
On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote: [..]
You're assuming the only use is roolback. It's not
Point taken. Can you shortly describe other use cases?
You use apps in one of those languages that static build by default. There is a security alert in one code component. You want to know which packages in your repo/mirror have been build using the broken piece of source code
Last time we disagreed on this topic my opinion was that static linking should imply bundled provides:
Provides: bundled(<as usual>) = <crate or module version>Hopefully something that could be automated for some stacks.
That makes it stack-specific
And anyway, the classical compiler attack (compiler that inserts backdoor while compiling) shows that special-casing some packages for special tracking does not work, pretty much anything that existed in the build root need to be tracked because it may be exploited one way or another, and spead the exploit to everything that used it.
On Fri, May 3, 2019 at 8:18 PM Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote:
Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit :
On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote:
Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit :
On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote: [..]
You're assuming the only use is roolback. It's not
Point taken. Can you shortly describe other use cases?
You use apps in one of those languages that static build by default. There is a security alert in one code component. You want to know which packages in your repo/mirror have been build using the broken piece of source code
Last time we disagreed on this topic my opinion was that static linking should imply bundled provides:
Provides: bundled(<as usual>) = <crate or module version>Hopefully something that could be automated for some stacks.
That makes it stack-specific
Bundling in general is very package-specific anyway.
And anyway, the classical compiler attack (compiler that inserts backdoor while compiling) shows that special-casing some packages for special tracking does not work, pretty much anything that existed in the build root need to be tracked because it may be exploited one way or another, and spead the exploit to everything that used it.
I definitely agree with that part, but I have no opinion on where that information should live.
Dridi
On Tue, Apr 30, 2019, at 10:14 PM, Neal Gompa wrote:
Second, do you not even know that Mock passes --nodeps to rpmbuild because the rpmdb in the chroot isn't necessarily compatible with rpm in the chroot? We currently don't allow rpmbuild to evaluate dependencies at all. We may change this if Koji switches to producing bootstrap chroots before producing the build chroot. So right now, that lookup is not even happening.
Awesome! I love learning how these things work! Thanks for sharing!
V/r, James Cassell
On Mon, 29 Apr 2019 at 20:09, Rex Dieter rdieter@gmail.com wrote: [..]
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Bollocks .. just sed/perl oneliner which will add BuildRequires: pkgconfig if in package is used any "BuildRequires: pkgconfig(<foo>) and remove from rpm dependencies autogenerator add "Requires: pkgconfig" if package has any on the list any pkgconfig file -> rebuild all affected packages. It should take ~1h for someone with proven packager priviledges.
kloczek
On Tue, Apr 30, 2019 at 9:47 AM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On Mon, 29 Apr 2019 at 20:09, Rex Dieter rdieter@gmail.com wrote: [..]
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Bollocks .. just sed/perl oneliner which will add BuildRequires: pkgconfig if in package is used any "BuildRequires: pkgconfig(<foo>) and remove from rpm dependencies autogenerator add "Requires: pkgconfig" if package has any on the list any pkgconfig file -> rebuild all affected packages. It should take ~1h for someone with proven packager priviledges.
Note that removing /usr/bin/pkg-config from the build environment also stops pkgconfig() Provides/Requires from being generated.
And while I am a provenpackager and capable of making these kinds of changes, I won't if I think they're not a good idea (like this one).
On Tue, 30 Apr 2019 at 14:59, Neal Gompa ngompa13@gmail.com wrote: [,,]
Bollocks .. just sed/perl oneliner which will add BuildRequires:
pkgconfig if in package is used any "BuildRequires: pkgconfig(<foo>) and remove from rpmdependencies autogenerator add "Requires: pkgconfig" if package has any on the list any pkgconfig file -> rebuild all affected packages.
It should take ~1h for someone with proven packager priviledges.
Note that removing /usr/bin/pkg-config from the build environment also stops pkgconfig() Provides/Requires from being generated.
And while I am a provenpackager and capable of making these kinds of changes, I won't if I think they're not a good idea (like this one).
So that is your problem that you don't see that serving any .pc file should not automatically cause "Requires: pkgconfig(<foo>)", and that such generator should not relay on availability of pkgconfig command in build env isn't correct solution as well.
If you still have some king of doubts that this is correct solution just please try to describe scenario when this may not work or will produce misleading results. Can you do this .. please?
Just in case if anyone woulds be asking did I tested this. I'm using above solution since I've first time opened issue ticket against rpm to drop adding pkgconfig (~two years ago). So far ItWorks(tm). Please find in attachment patch patch which I'm using. If you will have look closer you can find that this patch effectively removes only one line and everything else makes that generator shorter and depends only on POSIX sh (because it does not uses any bash specific extensions).
And on the bottom line If that problem would be solved we can start discussing dropping adding Requires.Private as automatic devel dependencies. And filter off Libs.Priovarte as only handful pf Fedora packages provides static libraries. This issue is as well related to meson messy behaviour. Coincidence but today I'v opened issue ticket against meson related to propagating Requires.Provate when meson is used to build only shared ABI. https://github.com/mesonbuild/meson/issues/5334
PS. No offence but when it comes to engineering usually when someone cannot prove/disprove something in technical context and to refuse something they are using only what they like/dislike usually I'm stoop listening. If you do not understand simple fact that you can only use your taste when you have two Correct(tm) solutions .. just change job.
kloczek
On Tue, Apr 30, 2019 at 8:50 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 30, 2019 at 9:47 AM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On Mon, 29 Apr 2019 at 20:09, Rex Dieter rdieter@gmail.com wrote: [..]
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Bollocks .. just sed/perl oneliner which will add BuildRequires: pkgconfig if in package is used any "BuildRequires: pkgconfig(<foo>) and remove from rpm dependencies autogenerator add "Requires: pkgconfig" if package has any on the list any pkgconfig file -> rebuild all affected packages. It should take ~1h for someone with proven packager priviledges.
Note that removing /usr/bin/pkg-config from the build environment also stops pkgconfig() Provides/Requires from being generated.
Indeed, synthesizing pkgconfig() entries based on the presence of .pc files is not necessarily sufficient enough. .pc files can define aliases using their own Provides rules. The information is best generated by using pkgconf to dump the dependency graph.
Similarly, the requirements may as well be generated by using pkgconf instead of trying to parse the .pc files with grep and sed itself as the syntax is not necessarily consistent. Many of the 'hotfix' releases in pkgconf involved mitigating problems where our parser would get confused by unexpected data in .pc files.
William
On Tue, Apr 30, 2019 at 10:04:55PM -0500, William Pitcock wrote:
On Tue, Apr 30, 2019 at 8:50 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 30, 2019 at 9:47 AM Tomasz Kłoczko kloczko.tomasz@gmail.com wrote:
On Mon, 29 Apr 2019 at 20:09, Rex Dieter rdieter@gmail.com wrote: [..]
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Bollocks .. just sed/perl oneliner which will add BuildRequires: pkgconfig if in package is used any "BuildRequires: pkgconfig(<foo>) and remove from rpm dependencies autogenerator add "Requires: pkgconfig" if package has any on the list any pkgconfig file -> rebuild all affected packages. It should take ~1h for someone with proven packager priviledges.
Note that removing /usr/bin/pkg-config from the build environment also stops pkgconfig() Provides/Requires from being generated.
Indeed, synthesizing pkgconfig() entries based on the presence of .pc files is not necessarily sufficient enough. .pc files can define aliases using their own Provides rules. The information is best generated by using pkgconf to dump the dependency graph.
Similarly, the requirements may as well be generated by using pkgconf instead of trying to parse the .pc files with grep and sed itself as the syntax is not necessarily consistent. Many of the 'hotfix' releases in pkgconf involved mitigating problems where our parser would get confused by unexpected data in .pc files.
Let me stop you right there: the generator we have (/usr/lib/rpm/pkgconfigdeps.sh) uses /usr/bin/pkg-config (which is now actually a compat interface provided by /usr/bin/pkgconf) already. grep and sed are not involved.
Zbyszek
On Wed, May 1, 2019, 6:15 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Tue, Apr 30, 2019 at 10:04:55PM -0500, William Pitcock wrote:
On Tue, Apr 30, 2019 at 8:50 AM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 30, 2019 at 9:47 AM Tomasz Kłoczko <
kloczko.tomasz@gmail.com> wrote:
On Mon, 29 Apr 2019 at 20:09, Rex Dieter rdieter@gmail.com wrote: [..]
The work required to fix packages affected by this disadvantage (potentially) far outweighs any advantage
Bollocks .. just sed/perl oneliner which will add BuildRequires:
pkgconfig if in package is used any "BuildRequires: pkgconfig(<foo>) and remove from rpm dependencies autogenerator add "Requires: pkgconfig" if package has any on the list any pkgconfig file -> rebuild all affected packages.
It should take ~1h for someone with proven packager priviledges.
Note that removing /usr/bin/pkg-config from the build environment also stops pkgconfig() Provides/Requires from being generated.
Indeed, synthesizing pkgconfig() entries based on the presence of .pc files is not necessarily sufficient enough. .pc files can define aliases using their own Provides rules. The information is best generated by using pkgconf to dump the dependency graph.
Similarly, the requirements may as well be generated by using pkgconf instead of trying to parse the .pc files with grep and sed itself as the syntax is not necessarily consistent. Many of the 'hotfix' releases in pkgconf involved mitigating problems where our parser would get confused by unexpected data in .pc files.
Let me stop you right there: the generator we have (/usr/lib/rpm/pkgconfigdeps.sh) uses /usr/bin/pkg-config (which is now actually a compat interface provided by /usr/bin/pkgconf) already. grep and sed are not involved.
I'm aware of that. Other dependency generators in the past have hit issues trying to parse .pc files by hand. My point is that it's better to just place the 200KB of utilities (staticly linking pkgconf may reduce that size if it is super important) RPM needs to get the job done right is better than trying to hack up a parser with shell tools.
William
Dne 28. 04. 19 v 22:55 Zbigniew Jędrzejewski-Szmek napsal(a):
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation).
I don't think that this is completely wrong. However that dependency should not be "Requires" but probably "Suggests". Not that we can really benefit from "Suggests".
Vít
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Apr 30, 2019 at 2:34 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 28. 04. 19 v 22:55 Zbigniew Jędrzejewski-Szmek napsal(a):
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation).
I don't think that this is completely wrong. However that dependency should not be "Requires" but probably "Suggests". Not that we can really benefit from "Suggests".
If it is made into a weak dependency (like Recommends or Suggests), then it doesn't show up in build roots, since we don't have weak dependencies on there. If it is Suggests, then _no one_ gets it, not even regular users...
Due to lack of popular support for the idea (to put it mildly), I won't be doing this.
Thank you all for participating in the discussion and good arguments (both pro and con).
Zbyszek
On Sun, Apr 28, 2019 at 08:55:56PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Hi everyone,
currently, we autogenerate a dependency on pkg-config for all rpms that ship a .pc file. "dnf repoquery --whatrequires /usr/bin/pkg-config" returns 4632 entries on my laptop.
This has always felt backward to me: those packages *provide* something that is used by pkg-config, they don't *require* pkg-config for anything. As an analogy, packages with headers are read by a C compiler, but we don't make them require gcc, and if a package ships an .so file, we don't add a dependency on the linker to it. Instead, anything which wants to consume .pc files should simply depend on the tools that consume those files (pkg-config, pkgconf, or a custom re-implementation).
Proposal: let's drop the autogenerated dependency on /usr/bin/pkg-config (this would require a trivial change in /usr/lib/rpm/pkgconfigdeps.sh).
Note: autogenerated Provides/Requires like pkgconfig(foo) are not part of this proposal.
Advantages:
- less entries in the dependency graph
- removal of illogical dependency
- less packages installed (pkgconf, pkgconf-m4, pkgconf-pkg-config, libpkgconf) (Those packages are small, maybe 200k together so this isn't a strong reason.)
Disadvantages:
- stuff that uses pkg-config or pkgconf will need to grow a dependency (e.g. meson which invokes /usr/bin/pkg-config internally). so there will be some churn.
Zbyszek
-
Dridi Boukelmoune -
Igor Gnatenko -
James Cassell -
Kalev Lember -
Lennart Poettering -
Neal Gompa -
Nicolas Mailhot -
Rex Dieter -
Tomasz Kłoczko -
Vít Ondruch -
William Pitcock -
Zbigniew Jędrzejewski-Szmek