Packages/YUMng finding strange dependencies

[m4z <[email protected]…>]

Another Packages-related issue. Example:

chaos:~ # yum deplist python-babel
Finding dependencies: 
package: python-babel.noarch 0.9.5-10.1
  dependency: /usr/bin/python
   provider: python-base.x86_64 2.6.5-2.14
   provider: python-base.i586 2.6.5-2.14
  dependency: python(abi) = 2.6
   provider: python-base.x86_64 2.6.5-2.14
   provider: python-base.i586 2.6.5-2.14
  dependency: python = 2.6
   provider: python.x86_64 2.6.5-2.11
   provider: python.i586 2.6.5-2.11
package: python-babel.noarch 0.9.5-1.3
  dependency: /usr/bin/python
   provider: python-base.x86_64 2.6.5-2.14
   provider: python-base.i586 2.6.5-2.14
  dependency: python(abi) = 2.6
   provider: python-base.x86_64 2.6.5-2.14
   provider: python-base.i586 2.6.5-2.14
  dependency: python = 2.6
   provider: python.x86_64 2.6.5-2.11
   provider: python.i586 2.6.5-2.11

...but the bcfg2-server (1.0.1 + Packages r6044) finds these:

Sep  7 09:19:48 chaos bcfg2-server[12081]: Packages: handling package requirement python-babel
Sep  7 09:19:48 chaos bcfg2-server[12081]: Packages: Package python-babel added requirements
    set(['/usr/bin/python', 'python-setuptools', 'python-devel', 'fdupes'])

And python-devel pulls in more stuff (but these are correct deps).

So basically I end up with these packages, which neither I nor yum want to have on the machine:

Incorrect entries:      5
 Package:fdupes             Package:linux-glibc-devel  Package:python-setuptools
 Package:glibc-devel        Package:python-devel

[m4z <…>]

The problem persists with 1.1.0.

[solj]

Is the python-babel package that the Packages plugin sees the same one as the client is using? Can you provide your YUMSource entry so that I can try and track down the issue?

[m4z <…>]

Replying to solj:

Is the python-babel package that the Packages plugin sees the same one as the client is using? Can you provide your YUMSource entry so that I can try and track down the issue?

How can I check if the python-babel package is the same? I'm not sure I understand the question.

The repository is a local mirror of ​http://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_11.3/

        <YUMSource>
                <Group>openSUSE11.3</Group>
                <Group>python-repo</Group>
                <RawURL>http://internal-server/mirror/python/openSUSE_11.3/</RawURL>
                <Version>11.3</Version>
                <Component>python</Component>
                <Arch>i386</Arch>
                <Arch>x86_64</Arch>
        </YUMSource>

(I tried to understand the dependencies manually by reading the xml files from the repo and (iirc) it seemed like Packages ignored the architecture of the packages, but given the time that has passed since then I'm really not sure about that.) The client is (or rather, was) in the groups openSUSE11.3, python-repo, and x86_64. On this particular setup, we switched back to Pkgmgr, but I have another setup where I can try switching to and debugging Packages.

[solj]

Looking at the spec file for the python-babel package in the repository you posted, it certainly looks like you _need_ these dependencies in order to install the package. I'm not sure why they wouldn't be required on the machine if it is installing this package.

#
# spec file for package python-babel (Version 0.9.5)
# 
# Copyright (c) 2011 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.

# Please submit bugfixes or comments via http://bugs.opensuse.org/
#

# norootforbuild

%{!?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)")}

%define mod_name babel

Name:           python-%{mod_name}
Version:        0.9.5
Release:        17.1
Url:            http://babel.edgewall.org/
Summary:        Internationalization utilities
License:        BSD
Group:          Development/Languages/Python
Source:         Babel-%{version}.tar.bz2
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
BuildRequires:  python-devel
BuildRequires:  python-setuptools
%if 0%{?suse_version} 
%py_requires
%if 0%{?suse_version} > 1010
BuildRequires:  fdupes
%endif
%if %{?suse_version: %{suse_version} > 1110} %{!?suse_version:1}
BuildArch:      noarch
%endif
%endif

%description
A collection of tools for internationalizing Python applications.
  
Authors:
--------
    Edgewall Software <[email protected]>

%prep
export CFLAGS="%{optflags}"
%setup -n Babel-%{version}
mv doc html

%build
python setup.py build

%install
python setup.py install --prefix=%{_prefix} --root=%{buildroot} %{?suse_version: --record-rpm=INSTALLED_FILES}
%if 0%{?suse_version} > 1010
%fdupes %{buildroot}
%endif

%clean
rm -rf %{buildroot}

%files %{?suse_version: -f INSTALLED_FILES}
%defattr(-,root,root,-) 
%doc COPYING ChangeLog INSTALL.txt README.txt html
%if 0%{!?suse_version:1}
%python_sitelib/%{mod_name}*
%python_sitelib/Babel*
%endif

%changelog
* Mon Dec 20 2010 [email protected]
- re-added dependency to python-setuptools
* Wed Dec 15 2010 [email protected]
- added documentation:
  * files: COPYING ChangeLog INSTALL.txt README.txt
  * HTML documentation
* Sat Dec 11 2010 [email protected]
- re-generated spec file with py2pack:
  * now builds for Fedora and Mandriva
* Wed Sep  1 2010 [email protected]
- added python-devel to buildrequires, to fix build on new python
  (because the package requires doctest, which requires unittest,
  which should probably both go into python-devel. (but this is
  subject to change))
- dropped check for obsolete SUSE version
* Sun Apr 25 2010 [email protected]
- Update to 0.9.5.
- Switch to noarch.
- Clean up spec.

[m4z <…>]

Thanks for your time!

If I'm not mistaken, a "BuildRequires" is only needed when the RPM is being built from the spec file (on the buildhost), but not at install time (that's "Requires").

Right now I'm only using Pkgmgr, so I haven't taken the time to see what kind of a difference this makes in the contents of the xml file in the rpm repository, and if that is what is confusing bcfg (if it is bcfgs fault at all). I'm planning to switch back to Packages in the distant future (before 2012, I'm hoping), but right now the priority for me is less-than-minor.

If I can provide any more information, please instruct me. If this open defect is bad for the stats, feel free to close it, since it seems I'm the only one having (had) this problem. Rest assured that I'll confirm if the problem still exists when I switch back to Packages. (;

[solj]

Replying to m4z <[email protected]…>:

Thanks for your time!

If I'm not mistaken, a "BuildRequires" is only needed when the RPM is being built from the spec file (on the buildhost), but not at install time (that's "Requires").

This is what I would have thought as well. However, the following leads me to believe that it's required in order to install the package since both setuptools and fdupes are BuildRequires.

%install
python setup.py install --prefix=%{_prefix} --root=%{buildroot} %{?suse_version: --record-rpm=INSTALLED_FILES}
%if 0%{?suse_version} > 1010
%fdupes %{buildroot}
%endif

Unfortunately, I don't have a machine to test this on, so I'll leave the ticket open and move it to a later roadmap so that you can test it when you have a chance.

[solj]

This should be resolved in 1.2. Please reopen if you are still seeing issues.