[opensuse-buildservice] Handling BuildRequires: Package = 1.2.3
I'm running 2.3 in a private install. I seem to be hitting into this bug: I have python2.7-numpy-1.6.2, python2.7-numpy-1.7.1, python2.7-pandas-0.9.1, and python2.7-pandas-0.11. The following is what needs to happen: Pandas 0.9.1 build and runtime requires NumPy 1.6.2 Pandas 0.11 build and runtime requires NumPy 1.7.1 I cannot seem to get OBS to find numpy 1.6.2. It keeps saying unresolvable. I've even moved 1.7.1 to another project, but somehow it still gets installed into the build VM. So two things: Why does OBS behave like this for BuildRequires? Why does it stop on first match? Is this behavior changed in 2.4? Here's the specs: # spec file for python pandas # # # This file and all modifications and additions to the pristine # package are under the same license as the package itself. # %global pybasever 2.7 %global __python_ver 2.7 %global __python %{_bindir}/python%{?pybasever} %global __os_install_post %{?__multiple_python_os_install_post} %if 0%{?fedora} > 12 || 0%{?rhel} > 6 %global with_python3 1 %else %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print (get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} %endif %global pkgname pandas Name: python2.7-pandas BuildRequires: python%{?__python_ver}-devel Version: 0.9.1 Release: 0 Summary: Library for pan-el da-ta analysis License: BSD Url: http://pypi.python.org/pypi/pandas/ Group: Development/Libraries/Python Source0: %{pkgname}-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildRequires: python2.7-numpy BuildRequires: python2.7-numpy-devel = 1.6.2 BuildRequires: python%{?__python_ver}-cython BuildRequires: python%{?__python_ver}-python-dateutil BuildRequires: gcc-c++ Requires: python2.7-numpy = 1.6.2 Requires: python%{?__python_ver}-python-dateutil %description Omitted %prep %setup -q -n %{pkgname}-%{version} %build %{__python} setup.py build %install Omitted %files ... Numpy: # # spec file for package python-numpy # # This file and all modifications and additions to the pristine # package are under the same license as the package itself. # %global pybasever 2.7 %global __python_ver 2.7 %global __python %{_bindir}/python%{?pybasever} %global __os_install_post %{?__multiple_python_os_install_post} %if 0%{?fedora} > 12 || 0%{?rhel} > 6 %global with_python3 1 %else %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} %endif %global pkgname numpy Name: python2.7-numpy BuildRequires: python%{?__python_ver}-devel Summary: NumPy: array processing for numbers, strings, records and objects License: BSD Group: Development/Libraries/Python Version: 1.6.2 Release: 0 Url: http://sourceforge.net/projects/numpy Vendor: openSUSE-Education BuildRequires: lapack BuildRequires: blas %if 0%{?rhel} < 6 BuildRequires: gcc44-c++ %else BuildRequires: gcc-c++ %endif BuildRequires: gcc-gfortran BuildRequires: atlas-devel BuildRequires: blas-devel BuildRequires: lapack-devel Requires: atlas-devel Obsoletes: numpy Source: numpy-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-build %description Omitted %package devel Summary: Development files for numpy applications Group: Development/Libraries/Python Requires: %{name} = %{version} Requires: python%{?__python_ver}-devel Requires: gcc-gfortran Requires: lapack Requires: blas %description devel This package contains files for developing applications using numpy. %prep %setup -q -n numpy-%{version} %build Omitted %install Omitted %clean rm -rf %{buildroot} %files Omitted %files devel %defattr(-,root,root) Omitted N�����r��y隊Z)z{.���Wlz��qﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǜ�)]���Ǿ� ޮ�^�ˬz��
As a follow-up to this, I had to delete ALL numpy packages, and re-create one with 1.6.2. It kept using 1.7.1 even though the OBS package was deleted. Once I recreated the 1.6.2 package, it picked that up as desired. This is extremely frustrating behavior. -Matt On Mon, 2013-11-18 at 21:46 +0000, Matthew Drobnak wrote:
I'm running 2.3 in a private install.
I seem to be hitting into this bug:
I have python2.7-numpy-1.6.2, python2.7-numpy-1.7.1, python2.7-pandas-0.9.1, and python2.7-pandas-0.11.
The following is what needs to happen:
Pandas 0.9.1 build and runtime requires NumPy 1.6.2 Pandas 0.11 build and runtime requires NumPy 1.7.1
I cannot seem to get OBS to find numpy 1.6.2. It keeps saying unresolvable. I've even moved 1.7.1 to another project, but somehow it still gets installed into the build VM.
So two things:
Why does OBS behave like this for BuildRequires? Why does it stop on first match?
Is this behavior changed in 2.4?
Here's the specs:
# spec file for python pandas # # # This file and all modifications and additions to the pristine # package are under the same license as the package itself. # %global pybasever 2.7 %global __python_ver 2.7 %global __python %{_bindir}/python%{?pybasever} %global __os_install_post %{?__multiple_python_os_install_post}
%if 0%{?fedora} > 12 || 0%{?rhel} > 6 %global with_python3 1 %else %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print (get_python_lib())")} %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} %endif
%global pkgname pandas
Name: python2.7-pandas BuildRequires: python%{?__python_ver}-devel Version: 0.9.1 Release: 0 Summary: Library for pan-el da-ta analysis License: BSD Url: http://pypi.python.org/pypi/pandas/ Group: Development/Libraries/Python Source0: %{pkgname}-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildRequires: python2.7-numpy BuildRequires: python2.7-numpy-devel = 1.6.2 BuildRequires: python%{?__python_ver}-cython BuildRequires: python%{?__python_ver}-python-dateutil BuildRequires: gcc-c++ Requires: python2.7-numpy = 1.6.2 Requires: python%{?__python_ver}-python-dateutil
%description Omitted
%prep %setup -q -n %{pkgname}-%{version}
%build %{__python} setup.py build
%install
Omitted
%files ...
Numpy:
# # spec file for package python-numpy # # This file and all modifications and additions to the pristine # package are under the same license as the package itself. #
%global pybasever 2.7 %global __python_ver 2.7 %global __python %{_bindir}/python%{?pybasever} %global __os_install_post %{?__multiple_python_os_install_post}
%if 0%{?fedora} > 12 || 0%{?rhel} > 6 %global with_python3 1 %else %{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")} %endif
%global pkgname numpy
Name: python2.7-numpy BuildRequires: python%{?__python_ver}-devel Summary: NumPy: array processing for numbers, strings, records and objects License: BSD Group: Development/Libraries/Python Version: 1.6.2 Release: 0 Url: http://sourceforge.net/projects/numpy Vendor: openSUSE-Education BuildRequires: lapack BuildRequires: blas %if 0%{?rhel} < 6 BuildRequires: gcc44-c++ %else BuildRequires: gcc-c++ %endif BuildRequires: gcc-gfortran BuildRequires: atlas-devel BuildRequires: blas-devel BuildRequires: lapack-devel Requires: atlas-devel Obsoletes: numpy Source: numpy-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-build
%description Omitted
%package devel Summary: Development files for numpy applications Group: Development/Libraries/Python Requires: %{name} = %{version} Requires: python%{?__python_ver}-devel Requires: gcc-gfortran Requires: lapack Requires: blas
%description devel This package contains files for developing applications using numpy.
%prep %setup -q -n numpy-%{version}
%build Omitted
%install Omitted
%clean rm -rf %{buildroot}
%files Omitted
%files devel %defattr(-,root,root) Omitted N�����r��y隊Z)z{.���Wlz��qﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǜ�)]���Ǿ� ޮ�^�ˬz�
N�����r��y隊Z)z{.���Wlz��qﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǜ�)]���Ǿ� ޮ�^�ˬz��
??n Monday 2013-11-18 22:46, Matthew Drobnak wrote:
I'm running 2.3 in a private install.
I seem to be hitting into this bug:
I have python2.7-numpy-1.6.2, python2.7-numpy-1.7.1, python2.7-pandas-0.9.1, and python2.7-pandas-0.11.
The following is what needs to happen:
Pandas 0.9.1 build and runtime requires NumPy 1.6.2 Pandas 0.11 build and runtime requires NumPy 1.7.1
I cannot seem to get OBS to find numpy 1.6.2. It keeps saying unresolvable. I've even moved 1.7.1 to another project, but somehow it still gets installed into the build VM.
So two things:
Why does OBS behave like this for BuildRequires? Why does it stop on first match?
It would seem that is the way how it was written. A name (such as python2.7-numpy-devel) maps to at most one .rpm file, which also hides any inherited packages (from <repository>) of any version.
BuildRequires: python2.7-numpy-devel = 1.6.2 -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Matthew Drobnak
Why does OBS behave like this for BuildRequires? Why does it stop on first match?
There is only one match. The repository where the packages are fetched from (see osc ls -b <project>) doesn't distinguish between different versions of the same package, it will carry the version that was built last. If you want to use different versions of the same package you need to either create separate projects or build in separate repositories for each version. 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
For build.opensuse.org, in the case of dependent items which have API changes (ie, it will break), those packages are put in different projects? That seems like a large increase in administrative overhead if you are using OBS as your main source of locally built software for an organization. Ie, now I have to keep track of all of the repositories that need to be put on a machine in order to be able to satisfy version requirements. Where would one go about modifying the code to change this behavior? -Matt On Tue, 2013-11-19 at 10:04 +0100, Andreas Schwab wrote:
Matthew Drobnak
writes: Why does OBS behave like this for BuildRequires? Why does it stop on first match?
There is only one match. The repository where the packages are fetched from (see osc ls -b <project>) doesn't distinguish between different versions of the same package, it will carry the version that was built last. If you want to use different versions of the same package you need to either create separate projects or build in separate repositories for each version.
Andreas.
N�����r��y隊Z)z{.���Wlz��qﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǜ�)]���Ǿ� ޮ�^�ˬz��
Anyone have any information on this? On Tue, 2013-11-19 at 13:54 +0000, Matthew Drobnak wrote:
For build.opensuse.org, in the case of dependent items which have API changes (ie, it will break), those packages are put in different projects?
That seems like a large increase in administrative overhead if you are using OBS as your main source of locally built software for an organization. Ie, now I have to keep track of all of the repositories that need to be put on a machine in order to be able to satisfy version requirements.
Where would one go about modifying the code to change this behavior?
-Matt On Tue, 2013-11-19 at 10:04 +0100, Andreas Schwab wrote:
Matthew Drobnak
writes: Why does OBS behave like this for BuildRequires? Why does it stop on first match?
There is only one match. The repository where the packages are fetched from (see osc ls -b <project>) doesn't distinguish between different versions of the same package, it will carry the version that was built last. If you want to use different versions of the same package you need to either create separate projects or build in separate repositories for each version.
Andreas.
On Tuesday 2013-11-19 14:54, Matthew Drobnak wrote:
For build.opensuse.org, in the case of dependent items which have API changes (ie, it will break), those packages are put in different projects?
You decide. Either you use different projects, or you rename the packages such that their names do not collide. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (3)
-
Andreas Schwab
-
Jan Engelhardt
-
Matthew Drobnak