print-provides ? #95

New Issue

ariadne · 2016-08-23T22:01:40Z

tpgxyz commented

2016-08-23 22:01:40 +00:00

(Migrated from github.com)

Hi,
i'm experimenting with replacing pkg-config on OpenMandriva Lx.
Our RPM development libraries contains autogenerated requires based on pkg-config --print-provides i.e.
pkgconfig(foobar)

https://github.com/rpm-software-management/rpm/blob/master/scripts/pkgconfigdeps.sh

Output message when building rpm with pkgconf:

DEBUG util.py:265: Processing files: phonon-devel-4.9.0-3.x86_64
DEBUG util.py:265: pkgconf: warning: --print-provides requested which is intentionally unimplemented, along with
DEBUG util.py:265: the rest of the Provides system. The Provides system is broken by design and requires loading every
DEBUG util.py:265: package module to calculate the dependency graph. In practice, there are no consumers of this system
DEBUG util.py:265: so it will remain unimplemented until such time that something actually uses it.

Question. Do you have any idea for a workaround for this issue ?

Hi, i'm experimenting with replacing pkg-config on OpenMandriva Lx. Our RPM development libraries contains autogenerated requires based on pkg-config --print-provides i.e. pkgconfig(foobar) https://github.com/rpm-software-management/rpm/blob/master/scripts/pkgconfigdeps.sh Output message when building rpm with pkgconf: DEBUG util.py:265: Processing files: phonon-devel-4.9.0-3.x86_64 DEBUG util.py:265: pkgconf: warning: --print-provides requested which is intentionally unimplemented, along with DEBUG util.py:265: the rest of the Provides system. The Provides system is broken by design and requires loading every DEBUG util.py:265: package module to calculate the dependency graph. In practice, there are no consumers of this system DEBUG util.py:265: so it will remain unimplemented until such time that something actually uses it. Question. Do you have any idea for a workaround for this issue ?

ariadne commented

2016-08-24 01:36:54 +00:00

yeah you don't need it, just scan for the .pc files instead

tpgxyz commented

2016-08-24 07:06:43 +00:00

(Migrated from github.com)

@kaniini
Sorry i do not understand :)
pkgconfigdeps.sh generates provides in RPM files like pkgconfig(foo), so others rpm packages which are dependant on foo.

@berolinux Have added a patch that provides support for print-provides

https://github.com/OpenMandrivaAssociation/pkgconf/blob/master/pkgconf-0.9.12-print-provides.patch

Can you please take a look on it, so i can prepare a pull request.

@kaniini Sorry i do not understand :) pkgconfigdeps.sh generates provides in RPM files like pkgconfig(foo), so others rpm packages which are dependant on foo. @berolinux Have added a patch that provides support for print-provides https://github.com/OpenMandrivaAssociation/pkgconf/blob/master/pkgconf-0.9.12-print-provides.patch Can you please take a look on it, so i can prepare a pull request.

berolinux commented

2016-08-24 10:40:46 +00:00

(Migrated from github.com)

To clairfy, my patch is not a complete implementation of --print-provides -- it just prints
pkg->realname = pkg->version (or pkg->realname if no version set).

But for every single .pc file on my box, that's actually what pkg-config --print-provides does -- looks like the dependency system was never used beyond that, and implementing that "print-provides lite" keeps the rpm dependency detector working.

To clairfy, my patch is not a complete implementation of --print-provides -- it just prints pkg->realname = pkg->version (or pkg->realname if no version set). But for every single .pc file on my box, that's actually what pkg-config --print-provides does -- looks like the dependency system was never used beyond that, and implementing that "print-provides lite" keeps the rpm dependency detector working.

ariadne commented

2016-08-24 15:41:01 +00:00

Right, that's why we never implemented it until now, nothing as far as we could tell actually uses it. :)

What I was saying earlier is that FreeBSD and Alpine (the main projects from which pkgconf came) just scan the pkg-config dirs and drop the names of the .pc files (with .pc stripped) to accomplish this.

Anyway, after talking with one of the RPM devs about this issue, they provided a reasonable usecase for the feature so we're going to revisit implementing it (with some changes in how it works so the overhead of supporting it is less severe).

Right, that's why we never implemented it until now, nothing as far as we could tell actually uses it. :) What I was saying earlier is that FreeBSD and Alpine (the main projects from which pkgconf came) just scan the pkg-config dirs and drop the names of the .pc files (with .pc stripped) to accomplish this. Anyway, after talking with one of the RPM devs about this issue, they provided a reasonable usecase for the feature so we're going to revisit implementing it (with some changes in how it works so the overhead of supporting it is less severe).

ariadne commented

2016-08-24 15:50:41 +00:00

@bapt took a look at freedesktop's implementation and discovered they actually don't implement the Provides system at all, other than --print-provides. The parser doesn't even read Provides: header at all!

That would explain why nobody is using it, it doesn't actually work.

@bapt took a look at freedesktop's implementation and discovered they actually don't implement the Provides system at all, other than `--print-provides`. The parser doesn't even read `Provides:` header at all! That would explain why nobody is using it, it doesn't actually work.

ariadne commented

2016-08-24 15:51:49 +00:00

So given that, we're going to roll a 1.0.1 with a stub --print-provides (same as pkg-config now), and roll 1.1 in a few weeks with an actual Provides support so people can actually use the functionality as intended.

So given that, we're going to roll a 1.0.1 with a stub `--print-provides` (same as pkg-config now), and roll 1.1 in a few weeks with an actual Provides support so people can actually use the functionality as intended.

ariadne commented

2016-08-24 16:08:05 +00:00

4a1b88fcc4 adds support for --print-provides.

4a1b88fcc42a518251eb4d21de4e662e77cd34c6 adds support for `--print-provides`.

tpgxyz commented

2016-08-24 16:52:49 +00:00

(Migrated from github.com)

@kaniini Thanks.

First RPM builds with pkgconf looks fine on x86_64, i586, armv7hl and aarch64 environments.
Soon we will start some mass rebuild of couple of tousand of packages so hopefully there will be no regression 👍

@kaniini Thanks. First RPM builds with pkgconf looks fine on x86_64, i586, armv7hl and aarch64 environments. Soon we will start some mass rebuild of couple of tousand of packages so hopefully there will be no regression :+1:

ariadne commented

2016-08-24 17:24:41 +00:00

There's a few issues with your specfile in Mandriva. Where should I report them?

tpgxyz commented

2016-08-24 18:23:20 +00:00

(Migrated from github.com)

@kaniini You can report them here https://github.com/OpenMandrivaAssociation/pkgconf or https://issues.openmandriva.org

ariadne commented

2016-08-25 00:32:58 +00:00

Cool, lets move the mandriva-specific details over to OpenMandrivaAssociation/pkgconf#1 for now.

Although I think there's probably elements of that specfile that should be documented for other RPM distributions once we figure out the details.

Cool, lets move the mandriva-specific details over to OpenMandrivaAssociation/pkgconf#1 for now. Although I think there's probably elements of that specfile that should be documented for other RPM distributions once we figure out the details.

ariadne commented

2016-08-26 00:40:20 +00:00

So, as an update this bug moves onto actually implementing Provides since pkg-config didn't actually do it. That will be done in the 1.1 series.

ariadne commented

2016-09-09 03:31:26 +00:00

A basic implementation of Provides rules has been implemented, which only works with PKGCONF_CMP_ANY dependency nodes.

Implementing support for versioning is mostly simple enough, but there is a question of what to do with Provides rules which only provide a PKGCONF_CMP_ANY comparison op and no version to match against. Should we interpret that as being compatible with any version, or should those Provides rules be ignored in a versioned comparison?

A basic implementation of Provides rules has been implemented, which only works with `PKGCONF_CMP_ANY` dependency nodes. Implementing support for versioning is mostly simple enough, but there is a question of what to do with Provides rules which only provide a `PKGCONF_CMP_ANY` comparison op and no version to match against. Should we interpret that as being compatible with _any_ version, or should those Provides rules be ignored in a versioned comparison?

Conan-Kudo commented

2016-09-09 03:35:24 +00:00

(Migrated from github.com)

@kaniini I guess we can't make the assumption to use the native .pc version for the alternate Provides if the version isn't specified for versioned checks? If not that, matching to any version makes sense, as ignoring it is probably not a good idea.

ariadne commented

2016-09-09 03:37:33 +00:00

I thought of that, but don't think it is a good idea. Consider OpenSSL vs LibreSSL where the version numbers are completely different. If LibreSSL uses a Provides entry, then the comparison may be incorrect if we use a version fallback.

I thought of that, but don't think it is a good idea. Consider OpenSSL vs LibreSSL where the version numbers are completely different. If LibreSSL uses a `Provides` entry, then the comparison may be incorrect if we use a version fallback.

Conan-Kudo commented

2016-09-09 03:45:55 +00:00

(Migrated from github.com)

@kaniini Wouldn't it make more sense for LibreSSL to ensure the OpenSSL Provides to match the version of the OpenSSL API they support?

ariadne commented

2016-09-09 03:53:14 +00:00

Sure. And of course, I would assume they would do so. I am more talking about edge cases where people don't really understand how the Provides rules should work.

Sure. And of course, I would assume they would do so. I am more talking about edge cases where people don't really understand how the `Provides` rules should work.

Sign in to join this conversation.