You are not logged in.
Hi,
The python-packaging, python-setuptools and python-pyparsing packages (and their python2 equivalents) in the [community] repositories each depend on one another during their build (i.e., their makedepends / depends fields list each other) leading to a circular dependency issue. Namely:
* python-packaging's build depends on python-pyparsing and python-setuptools
* python-pyparsing's build depends on python-setuptools
* python-setuptools' build depends on python-packaging
the reason this is relevant (as I guess you're thinking, "Well, what do you care, you're an end-user of Arch Linux not a developer, aren't you? So you should have access to the [community] repo anyway?") is that I am building these packages in my Open Build Service Project (https://build.opensuse.org/project/show … tra:python) and this circular dependency issue is preventing every one of these packages from being built. See the OBS does not provide the [community] repo for make dependency resolution. I dislike this fact (i.e., that the OBS does not provide the [community] repo) as much as any packager would, but unfortunately I cannot fix this issue myself, so I just have to live with it and work around it. So I am here to ask how the [community] packagers have managed to overcome this circular dependency issue, so that I can follow in their footsteps. If you have another solution for me (i.e., one that is not used by [community] packagers) I will be equally willing to hear it.
I asked this question at the openSUSE Forums (namely their Open Build Service subforum https://forums.opensuse.org/showthread. … rch_Extra) also, if this is relevant.
Thanks for your time,
Brenton
Last edited by fusion809 (2016-03-24 14:11:18)
Offline
Only arch devs can answer that, and i think the chance of them seeing this topic is small.
Felix Yan did the last update, Alexander Rødseth and Ángel Velásquez are also mentioned as maintainer.
You can try posting about this on arch-general, but i think contacting them directly has a better chance of success.
Contact details for arch devs can be found on https://www.archlinux.org/people/developers/
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
* python-setuptools' build depends on python-packaging
That's wrong. Setuptools only needs Python itself, to build, with Python2 at least. I see no additional dependency mentioned at installation instructions.
Offline
Upstream uses a vendored copy of the "packaging" module, which is why the Arch Linux package has an install dep on python{,2}-packaging.
It was "bootstrapped" in the sense that:
originally the package had the vendored copy.
Build "packaging" with current "setuptools".
Strip vendored "packaging" and use the "packaging" package to build a de-vendored copy of "setuptools"
...
Or so I deduce from the svntogit history but I am pretty sure I am right.
Last edited by eschwartz (2016-03-25 16:58:17)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Yeah, The setuptools source contains a bundled copy of "packaging".
I don't see a worthwhile benefit here in Arch forcing the use of the system "packaging".
Offline
Yeah, The setuptools source contains a bundled copy of "packaging".
I don't see a worthwhile benefit here in Arch forcing the use of the system "packaging".
I'm not sure what you are trying to say.
It is the same benefit as when forcing the use of the system anything.
Why do distros provide software packages integrated with the system software, rather than doing like Windows and providing software with bundled dependencies?
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
No, this is a special case - the bundling is just *Python scripts*. Far less important than e.g. bundling zlib.
Downside: An unnecessary circular build dependency.
Upside: Almost nothing.
Offline
Arch is a binary distro, circular deps aren't that big of a deal.
Upside pretty much the same as it would be for any other system lib, updates only happen in one place. It misses the memory benefits of compiled shared libs, but that's it.
Online
No, this is a special case - the bundling is just *Python scripts*. Far less important than e.g. bundling zlib.
Downside: An unnecessary circular build dependency.
Upside: Almost nothing.
What is this completely arbitrary distinction between scripted and binary code you are making?
Debundling, consolidating, reducing duplication and doing the same update only once... is the same regardless of what language a package is written in.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline