[opensuse-buildservice] introducing new macros across the whole OBS?
Hello, in relation to the python single-spec initiative, I have designed a set of new macros that allow significant automation in building Python packages. However, these are constrained by the %python_module macro used in BuildRequires. The purpose of this macro is to expand %{python_module foo} to python2-foo, python3-foo, etc., based on which python flavors are build targets for the package. Obviously, the buildservice itself must be able to do this expansion, otherwise it can't resolve the build requirements. So far I have solved this by placing all the macros in prjconf. But this is not viable if I want my macros to be available everywhere. I can create a "python-macros" package for all the other macros, and buildrequire it, in order to make the packages build in any distro that has this package, but I can't do the same for %python_module. Is it possible to make the buildservice itself recognize this macro, or place it in some sort of global prjconf? Ideally without triggering a full rebuild of everything? Or do you have any tips for alternate solutions? One thing that occured to me, instead of relying on macros, turn "python-foo" packages into metapackages requiring the respective "python2-foo", "python3-foo" etc., and then BuildRequire the metapackage. I don't have a clear idea about how well this would work, it seems rather problematic. I don't want to make packagers list the buildrequires by hand, because the requirements can be numerous and we also want to be able to add more python flavors and expand the build requirements accordingly. thanks for any tips m.
On Thu, Nov 10, 2016 at 7:49 AM, jan matejek <jmatejek@suse.com> wrote:
Hello, in relation to the python single-spec initiative, I have designed a set of new macros that allow significant automation in building Python packages.
However, these are constrained by the %python_module macro used in BuildRequires. The purpose of this macro is to expand %{python_module foo} to python2-foo, python3-foo, etc., based on which python flavors are build targets for the package. Obviously, the buildservice itself must be able to do this expansion, otherwise it can't resolve the build requirements.
So far I have solved this by placing all the macros in prjconf. But this is not viable if I want my macros to be available everywhere. I can create a "python-macros" package for all the other macros, and buildrequire it, in order to make the packages build in any distro that has this package, but I can't do the same for %python_module.
Is it possible to make the buildservice itself recognize this macro, or place it in some sort of global prjconf? Ideally without triggering a full rebuild of everything? Or do you have any tips for alternate solutions?
One thing that occured to me, instead of relying on macros, turn "python-foo" packages into metapackages requiring the respective "python2-foo", "python3-foo" etc., and then BuildRequire the metapackage. I don't have a clear idea about how well this would work, it seems rather problematic.
I don't want to make packagers list the buildrequires by hand, because the requirements can be numerous and we also want to be able to add more python flavors and expand the build requirements accordingly.
thanks for any tips m.
Why not pull in the dependency generator I upstreamed into RPM[1] into openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and Mageia is using an earlier variant of it now. It establishes common names for Python packages that provide egg-info or dist-info data (egg/wheel metadata installed on the system) that can be used for standardizing how Python dependencies are referenced. Fedora is currently only using it for Provides generation at the moment, but Mageia uses it for Provides and Requires generation. That would make it less onerous in general to package Python stuff, as it would gain useful dependency generation like Perl and Ruby have. Tools like pyp2rpm[4] can use these names for generating good spec files that can build packages properly. Petr Viktorin gave a presentation at Flock 2016[5][6] about the future of Python packaging in Fedora, with this as a key staple. [1]: https://github.com/rpm-software-management/rpm/blob/master/scripts/pythondis... [2]: http://pkgs.fedoraproject.org/cgit/rpms/rpm.git/tree/ [3]: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproje... [4]: https://github.com/fedora-python/pyp2rpm [5]: https://speakerdeck.com/encukou/python-packaging-in-fedora [6]: https://www.youtube.com/watch?v=rp5jq-25nZg -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.11.2016 14:02, Neal Gompa wrote:
Why not pull in the dependency generator I upstreamed into RPM[1] into openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and Mageia is using an earlier variant of it now. It establishes common names for Python packages that provide egg-info or dist-info data (egg/wheel metadata installed on the system) that can be used for standardizing how Python dependencies are referenced.
this is certainly very useful and we're looking into it, but it doesn't seem to solve my question? to restate, I need to configure BuildRequires (not install-time requirements) and pull in, as automagically as possible, all rpm packages of "python module foo" for all supported pythons (that is python2 and python3 at the moment, pypy3 in the near future (hopefully)) also, BuildRequires are evaluated by OBS before rpmbuild starts, so I can't rely on the usual ways of injecting macros into the build environment. (i'd also be interested in what Fedora has to say about the single-spec thing, [1]. ISTM you don't do anything similar at the moment? but i suppose that's for a different thread altogether) [1] https://lists.opensuse.org/opensuse-packaging/2016-10/msg00031.html
On Thu, Nov 10, 2016 at 8:11 AM, jan matejek <jmatejek@suse.com> wrote:
On 10.11.2016 14:02, Neal Gompa wrote:
Why not pull in the dependency generator I upstreamed into RPM[1] into openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and Mageia is using an earlier variant of it now. It establishes common names for Python packages that provide egg-info or dist-info data (egg/wheel metadata installed on the system) that can be used for standardizing how Python dependencies are referenced.
this is certainly very useful and we're looking into it, but it doesn't seem to solve my question?
to restate, I need to configure BuildRequires (not install-time requirements) and pull in, as automagically as possible, all rpm packages of "python module foo" for all supported pythons (that is python2 and python3 at the moment, pypy3 in the near future (hopefully))
Having the standardized names means you can just read requirements.txt or whatever and generate the list and expect it to work. It's a step that'd be required for that. OBS would likely need to grow the ability to run something like pyp2rpm spec generator before starting the build, which means being able to read requirements.txt or setup.py for the deps and resolving them properly.
also, BuildRequires are evaluated by OBS before rpmbuild starts, so I can't rely on the usual ways of injecting macros into the build environment.
(i'd also be interested in what Fedora has to say about the single-spec thing, [1]. ISTM you don't do anything similar at the moment? but i suppose that's for a different thread altogether)
[1] https://lists.opensuse.org/opensuse-packaging/2016-10/msg00031.html
As far as I know, openSUSE was the *only* distribution *not* doing single spec Python 2/3 packaging. Fedora[1] and Mageia[2] both do. [1]: https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file [2]: https://wiki.mageia.org/en/Python_policy#Samples -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, Nov 10, 2016 at 8:16 AM, Neal Gompa <ngompa13@gmail.com> wrote:
On Thu, Nov 10, 2016 at 8:11 AM, jan matejek <jmatejek@suse.com> wrote:
On 10.11.2016 14:02, Neal Gompa wrote:
Why not pull in the dependency generator I upstreamed into RPM[1] into openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and Mageia is using an earlier variant of it now. It establishes common names for Python packages that provide egg-info or dist-info data (egg/wheel metadata installed on the system) that can be used for standardizing how Python dependencies are referenced.
this is certainly very useful and we're looking into it, but it doesn't seem to solve my question?
to restate, I need to configure BuildRequires (not install-time requirements) and pull in, as automagically as possible, all rpm packages of "python module foo" for all supported pythons (that is python2 and python3 at the moment, pypy3 in the near future (hopefully))
Having the standardized names means you can just read requirements.txt or whatever and generate the list and expect it to work. It's a step that'd be required for that. OBS would likely need to grow the ability to run something like pyp2rpm spec generator before starting the build, which means being able to read requirements.txt or setup.py for the deps and resolving them properly.
also, BuildRequires are evaluated by OBS before rpmbuild starts, so I can't rely on the usual ways of injecting macros into the build environment.
(i'd also be interested in what Fedora has to say about the single-spec thing, [1]. ISTM you don't do anything similar at the moment? but i suppose that's for a different thread altogether)
[1] https://lists.opensuse.org/opensuse-packaging/2016-10/msg00031.html
As far as I know, openSUSE was the *only* distribution *not* doing single spec Python 2/3 packaging. Fedora[1] and Mageia[2] both do.
[1]: https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file [2]: https://wiki.mageia.org/en/Python_policy#Samples
Also, Fedora and Mageia (and other related distributions) have a shared set of macros for Python packaging[1]. Unfortunately, openSUSE does not use these, so Python module packaging differs quite a bit between openSUSE and the other RPM based distributions I work on. [1]: http://pkgs.fedoraproject.org/cgit/rpms/python-rpm-macros.git/tree/ -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.11.2016 14:16, Neal Gompa wrote:
As far as I know, openSUSE was the *only* distribution *not* doing single spec Python 2/3 packaging. Fedora[1] and Mageia[2] both do.
and as far as I can tell, we're now the only ones to (try to) automate this as opposed to writing everything in the spec file explicitly ;) Which, for instance, would allow us to support pypy across the board with little additional effort. Maybe that's where pyp2rpm comes in at Fedora? Does it regenerate the spec for every build? m.
On Thu, Nov 10, 2016 at 8:24 AM, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 14:16, Neal Gompa wrote:
As far as I know, openSUSE was the *only* distribution *not* doing single spec Python 2/3 packaging. Fedora[1] and Mageia[2] both do.
and as far as I can tell, we're now the only ones to (try to) automate this as opposed to writing everything in the spec file explicitly ;)
Which, for instance, would allow us to support pypy across the board with little additional effort.
Maybe that's where pyp2rpm comes in at Fedora? Does it regenerate the spec for every build?
m.
Yes. We also have it hooked up to our COPR service to autogenerate them fairly regularly[1][2][3] as a way to help make pyp2rpm even more useful and reliable. [1]: https://copr.fedorainfracloud.org/coprs/g/copr/PyPi/ [2]: https://copr.fedorainfracloud.org/coprs/g/copr/PyPI2/ [3]: https://copr.fedorainfracloud.org/coprs/g/copr/PyPI3/ -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Nov 10 2016, jan matejek <jmatejek@suse.com> wrote:
Is it possible to make the buildservice itself recognize this macro, or place it in some sort of global prjconf?
Project configs are inherited across repo paths, so I'm not sure what you mean with global prjconf. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.11.2016 14:03, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.com> wrote:
Is it possible to make the buildservice itself recognize this macro, or place it in some sort of global prjconf?
Project configs are inherited across repo paths, so I'm not sure what you mean with global prjconf.
I'm not sure either, that's why I'm asking here ;) What macros are supported at buildrequires evaluation time? How are these configured? I know that only single-line expansion works, so there must be some sort of special handling. An option could be to put this into prjconf of Factory and other distros? So everyone building for Factory, directly or indirectly, would also inherit the macros? However, I'm told that changing prjconf of old distributions would trigger unwanted rebuilds and we definitely don't want that. Does it mean that something like %python_module can never be supported on old distros?
Andreas.
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
An option could be to put this into prjconf of Factory and other distros?
Why other ditros? This is surely a factory thing. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.11.2016 14:27, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
An option could be to put this into prjconf of Factory and other distros?
Why other ditros? This is surely a factory thing.
packages using the new macros are strictly incompatible with older distros. an updated package would only build for factory, unless you put a huge conditional that lists buildrequires by hand for older distros, which kinda defeats the point.
Andreas.
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 14:27, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
An option could be to put this into prjconf of Factory and other distros?
Why other ditros? This is surely a factory thing.
packages using the new macros are strictly incompatible with older distros.
What's your point then? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.11.2016 15:44, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 14:27, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
An option could be to put this into prjconf of Factory and other distros?
Why other ditros? This is surely a factory thing.
packages using the new macros are strictly incompatible with older distros.
What's your point then?
well, the primary reason for this incompatibility is the %python_module macro, which i would need to add to said older distros. the other macros can be solved in several ways, the most promising is making and buildrequiring a "python-rpm-macros" package, that can be either submitted to older distros, or copypac'd/linked to projects as required. crucially, this does not work for macros used in BuildRequires which is the whole point of this thread? regards m.
Andreas.
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 15:44, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 14:27, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
An option could be to put this into prjconf of Factory and other distros?
Why other ditros? This is surely a factory thing.
packages using the new macros are strictly incompatible with older distros.
What's your point then?
well, the primary reason for this incompatibility is the %python_module macro, which i would need to add to said older distros.
Why would that be needed? Only factory-based repositories will be using it, IIUC. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.11.2016 16:15, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 15:44, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 14:27, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
An option could be to put this into prjconf of Factory and other distros?
Why other ditros? This is surely a factory thing.
packages using the new macros are strictly incompatible with older distros.
What's your point then?
well, the primary reason for this incompatibility is the %python_module macro, which i would need to add to said older distros.
Why would that be needed? Only factory-based repositories will be using it, IIUC.
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released. So do many personal / topical / private repositories. We need to support all of that, otherwise nobody will switch to the new macros.
Andreas.
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released.
So do many personal / topical / private repositories.
We need to support all of that, otherwise nobody will switch to the new macros.
No problem, set up the project config of devel:languages:python as you like. That's your anchor. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 10.11.2016 16:45, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released.
So do many personal / topical / private repositories.
We need to support all of that, otherwise nobody will switch to the new macros.
No problem, set up the project config of devel:languages:python as you like. That's your anchor.
But then everyone who wants to build a python package would need to fork from d:l:py. This is not the case in practice. m.
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 16:45, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released.
So do many personal / topical / private repositories.
We need to support all of that, otherwise nobody will switch to the new macros.
No problem, set up the project config of devel:languages:python as you like. That's your anchor.
But then everyone who wants to build a python package would need to fork from d:l:py. This is not the case in practice.
Any project that wants the updated python-rpm-macros package will either have to build against d:l:py (or factory) or carry over the corresponding project config settings. That includes any :Update project. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, Nov 10, 2016 at 11:18 AM, Andreas Schwab <schwab@suse.de> wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 16:45, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released.
So do many personal / topical / private repositories.
We need to support all of that, otherwise nobody will switch to the new macros.
No problem, set up the project config of devel:languages:python as you like. That's your anchor.
But then everyone who wants to build a python package would need to fork from d:l:py. This is not the case in practice.
Any project that wants the updated python-rpm-macros package will either have to build against d:l:py (or factory) or carry over the corresponding project config settings. That includes any :Update project.
Andreas.
What percentage of projects have a python package in them? Since these are _new_ macros, what would be the danger of adding them to the base distros: 13.1, 13.2, 42.1, 42.2 and factory. If there is a concern some projects already define them for a different purpose, couldn't OBS be scanned for existing macros with the same name and then eliminate the conflicts prior to instituting these new macros. I for one, would prefer to see these macros either global to OBS, or at least global to the openSUSE repositories. Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 11/11/2016 05:43 AM, Greg Freemyer wrote:
On Thu, Nov 10, 2016 at 11:18 AM, Andreas Schwab <schwab@suse.de> wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 16:45, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released.
So do many personal / topical / private repositories.
We need to support all of that, otherwise nobody will switch to the new macros.
No problem, set up the project config of devel:languages:python as you like. That's your anchor.
But then everyone who wants to build a python package would need to fork from d:l:py. This is not the case in practice.
Any project that wants the updated python-rpm-macros package will either have to build against d:l:py (or factory) or carry over the corresponding project config settings. That includes any :Update project.
Andreas.
What percentage of projects have a python package in them?
Since these are _new_ macros, what would be the danger of adding them to the base distros: 13.1, 13.2, 42.1, 42.2 and factory.
I think as stated previously, know one has mentioned a way of doing this without triggering a rebuild of these repo's which is undesirable and unwanted. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Nov 10, 2016 at 4:31 PM, Simon Lees <sflees@suse.de> wrote:
On 11/11/2016 05:43 AM, Greg Freemyer wrote:
On Thu, Nov 10, 2016 at 11:18 AM, Andreas Schwab <schwab@suse.de> wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
On 10.11.2016 16:45, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released.
So do many personal / topical / private repositories.
We need to support all of that, otherwise nobody will switch to the new macros.
No problem, set up the project config of devel:languages:python as you like. That's your anchor.
But then everyone who wants to build a python package would need to fork from d:l:py. This is not the case in practice.
Any project that wants the updated python-rpm-macros package will either have to build against d:l:py (or factory) or carry over the corresponding project config settings. That includes any :Update project.
Andreas.
What percentage of projects have a python package in them?
Since these are _new_ macros, what would be the danger of adding them to the base distros: 13.1, 13.2, 42.1, 42.2 and factory.
I think as stated previously, know one has mentioned a way of doing this without triggering a rebuild of these repo's which is undesirable and unwanted.
--
Simon Lees (Simotek)
Surely someone with backend access to the files could insert the change without triggering a full rebuild. Touch can backdate files. If the trigger is in a database hash compare, a direct update of the hash field could be done, etc. Obviously its a non-standard process, but I would be very surprised if it can't be done. Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Am 10.11.2016 um 16:50 schrieb jan matejek:
On 10.11.2016 16:45, Andreas Schwab wrote:
On Nov 10 2016, jan matejek <jmatejek@suse.cz> wrote:
devel:languages:python itself builds for distros as old as SLE11. we might drop that soon, but still there's SLE12_backports, 13.2 and both Leaps, both of which are "old distros" for the purpose of this discussion, seeing as they're already released.
So do many personal / topical / private repositories.
We need to support all of that, otherwise nobody will switch to the new macros.
No problem, set up the project config of devel:languages:python as you like. That's your anchor.
But then everyone who wants to build a python package would need to fork from d:l:py. This is not the case in practice.
When we switched to new set of perl packages, we had every new package buildrequire perl-macros. This way if someone branched a new perl package, he would be told to also branch perl-macros into his prj if he cared for backports. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn.
participants (7)
-
Andreas Schwab -
Greg Freemyer -
jan matejek -
jan matejek -
Neal Gompa -
Simon Lees -
Stephan Kulow