Hello all,
It's been a while since I messaged this list about the new dependency generator being upstreamed into RPM[0]. Since then, I've taken your valuable feedback and incorporated it into the version that now sits in RPM git master[1].
A little bit ago, I pushed a package to Copr[2] that includes this updated dependency generator, and I would love for people to take a look at it, try it out, and see how well it works. Instructions on setting up and configuring are on the Copr page.
I'd also love this become enabled in Fedora's Python stack for Fedora 25, giving us nice Provides/Requires chains that are independent of the package name, but map more closely to PyPi names that people would recognize from using pip or other tools.
We already have similar things in place for Ruby, Mono, Perl, and even MinGW in Fedora, so it'd be nice to have it on the Python side, too.
Best regards, Neal
[0]: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproje...
[1]: https://github.com/rpm-software-management/rpm/blob/master/scripts/pythondis...
[2]: https://copr.fedorainfracloud.org/coprs/ngompa/rpm-depgen-pythondistdeps/
On 11.4.2016 05:29, Neal Gompa wrote:
Hello all,
It's been a while since I messaged this list about the new dependency generator being upstreamed into RPM[0]. Since then, I've taken your valuable feedback and incorporated it into the version that now sits in RPM git master[1].
A little bit ago, I pushed a package to Copr[2] that includes this updated dependency generator, and I would love for people to take a look at it, try it out, and see how well it works. Instructions on setting up and configuring are on the Copr page.
I'd also love this become enabled in Fedora's Python stack for Fedora 25, giving us nice Provides/Requires chains that are independent of the package name, but map more closely to PyPi names that people would recognize from using pip or other tools.
We already have similar things in place for Ruby, Mono, Perl, and even MinGW in Fedora, so it'd be nice to have it on the Python side, too.
Best regards, Neal
Hi, this looks very good.
I tried to build some arched packages and was wondering, if there shouldn't be %{?_isa} included at the end of the provide name?
Something like:
Provided form the 64bit package:
python3.5dist(foo)(x86-64) python3.5dist(foo)
Provided form the 32bit package:
python3.5dist(foo)
On Wed, Apr 13, 2016 at 8:43 AM, Miro Hrončok mhroncok@redhat.com wrote:
Hi, this looks very good.
I tried to build some arched packages and was wondering, if there shouldn't be %{?_isa} included at the end of the provide name?
Something like:
Provided form the 64bit package: python3.5dist(foo)(x86-64) python3.5dist(foo) Provided form the 32bit package: python3.5dist(foo)
I'm not sure. Historically, dependency generators of this kind don't include the architecture information because of the issues related to determining whether a package is a noarch package or an archful package (or if it needs to transition from one to the other). It's somewhat easier to tell on 64-bit (due to path differences), but harder on 32-bit, because the paths are the same.
I'm also not sure what happens when you just naively add %{?_isa} to a Provides/Requires set in a noarch package.
I'm not sure. Historically, dependency generators of this kind don't include the architecture information because of the issues related to determining whether a package is a noarch package or an archful package (or if it needs to transition from one to the other). It's somewhat easier to tell on 64-bit (due to path differences), but harder on 32-bit, because the paths are the same.
I'm also not sure what happens when you just naively add %{?_isa} to a Provides/Requires set in a noarch package.
I'm not entirely sure that including the arch would be necessary, considering the repos are already split up based on arch. Seems to me that it would be a little extra overhead and a fair bit of added complexity, and I don't see any gain.
John.
python-devel@lists.fedoraproject.org
-
John Dulaney -
Miro Hrončok -
Neal Gompa