threads / discuss / 22450

[RFH] rpm packaging failure

Subject: [RFH] rpm packaging failure

## tl;dr

11 messages between Jan 30, 2010 and Jan 31, 2010.

replies: 10people: 5as markdown or json

Junio C Hamano· Jan 30, 2010, 09:24 UTC · lore

Subject: [PATCH] experimental RPM spec change

"make rpm" with recent 'master' fails with:

    RPM build errors:
        Installed (but unpackaged) file(s) found:
       /usr/lib/python2.6/site-packages/git_remote_helpers-0.1.0-py2.6.egg-info
       /usr/lib/python2.6/site-packages/git_remote_helpers/__init__.py
       /usr/lib/python2.6/site-packages/git_remote_helpers/__init__.pyc
       /usr/lib/python2.6/site-packages/git_remote_helpers/git/__init__.py
       /usr/lib/python2.6/site-packages/git_remote_helpers/git/__init__.pyc
       /usr/lib/python2.6/site-packages/git_remote_helpers/git/git.py
       /usr/lib/python2.6/site-packages/git_remote_helpers/git/git.pyc
       /usr/lib/python2.6/site-packages/git_remote_helpers/util.py
       /usr/lib/python2.6/site-packages/git_remote_helpers/util.pyc

Here is an attempt to fix it, but help is very appreciated, as I don't know what the accepted way is to ship Python modules is in the RPM world.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git.spec.in |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git.spec.in b/git.spec.in
index ab224f7..1aeba90 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -121,6 +121,7 @@ find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
 (find $RPM_BUILD_ROOT%{perl_vendorlib} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
 %if %{!?_without_docs:1}0
 (find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "archimport|svn|git-cvs|email|gitk|git-gui|git-citool" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_libdir}/python* -type f | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
 %else
 rm -rf $RPM_BUILD_ROOT%{_mandir}
 %endif

-- 
1.7.0.rc0

Todd Zullinger· Jan 30, 2010, 15:19 UTC · re: Junio C Hamano · lore

Re: [RFH] rpm packaging failure

Junio C Hamano wrote:

> Here is an attempt to fix it, but help is very appreciated, as I don't
> know what the accepted way is to ship Python modules is in the RPM world.

Perhaps this will work well. I only tested it on Fedora 10, but I believe it should work on RHEL/CentOS and most other rpm-based distros. We may well want to package the python bits in a subpackage, much as the perl modules are. Anyone have thoughts on that?

-->8--
Subject: [PATCH] RPM spec: Package git_remote_helper python files

Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
 git.spec.in |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/git.spec.in b/git.spec.in
index ab224f7..575156c 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -1,4 +1,5 @@
 # Pass --without docs to rpmbuild if you don't want the documentation
+%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
 
 Name: 		git
 Version: 	@@VERSION@@
@@ -9,6 +10,7 @@ Group: 		Development/Tools
 URL: 		http://kernel.org/pub/software/scm/git/
 Source: 	http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
 BuildRequires:	zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel, gettext  %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
+BuildRequires:	python
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:	perl-Git = %{version}-%{release}
@@ -134,6 +136,7 @@ rm -rf $RPM_BUILD_ROOT
 %doc README COPYING Documentation/*.txt
 %{!?_without_docs: %doc Documentation/*.html Documentation/howto}
 %{!?_without_docs: %doc Documentation/technical}
+%{python_sitelib}/*
 
 %files svn
 %defattr(-,root,root)
@@ -190,6 +193,9 @@ rm -rf $RPM_BUILD_ROOT
 # No files for you!
 
 %changelog
+* Sat Jan 30 2010 Todd Zullinger <tmz@pobox.com>
+- Include git_remote_helper python files
+
 * Mon Feb 04 2009 David J. Mellor <dmellor@whistlingcat.com>
 - fixed broken git help -w after renaming the git-core package to git.

-- 
1.6.6

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't hit a man when he's down -- kick him; it's easier.

Junio C Hamano· Jan 30, 2010, 17:10 UTC · re: Todd Zullinger · lore

Re: [RFH] rpm packaging failure

Todd Zullinger <tmz@pobox.com> writes:

Show 8 quoted lines

> Junio C Hamano wrote:
>> Here is an attempt to fix it, but help is very appreciated, as I don't
>> know what the accepted way is to ship Python modules is in the RPM world.
>
> Perhaps this will work well.  I only tested it on Fedora 10, but I
> believe it should work on RHEL/CentOS and most other rpm-based
> distros.  We may well want to package the python bits in a subpackage,
> much as the perl modules are.  Anyone have thoughts on that?

Thanks.

The files that are problematic are only infrastructure bits to support "remote helpers written in Python" (which we don't ship at all yet).

Once we start shipping real remote helpers, separating Python bits out into its own package would make a lot of sense. People who want to use foreign scm helpers that happen to be written in Python would need it, and all others don't.

But I suspect that a safer alternative at least for 1.7.0 would be to leave these files out altogether. As I understand the current state, it is an unused but required package dependency on Python, a downside without an upside. Is it Ok with "remote helpers in Python" folks (I think Sverre and Johan are principal parties), or did I miss some reason that these need to be installed/installable, perhaps to support third party packages that already exist?

And if the removal is the way to go for 1.7.0, is the following an Ok approach to do that removal (this is asking an RPM help again to Todd)?

 git.spec.in |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/git.spec.in b/git.spec.in
index ab224f7..ec3451a 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -112,6 +112,7 @@ rm -rf $RPM_BUILD_ROOT
 make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" DESTDIR=$RPM_BUILD_ROOT \
      %{path_settings} \
      INSTALLDIRS=vendor install %{!?_without_docs: install-doc}
+rm -fr $RPM_BUILD_ROOT%{_libdir}/python*
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
@@ -190,6 +191,9 @@ rm -rf $RPM_BUILD_ROOT
 # No files for you!
 
 %changelog
+* Sat Jan 30 2010 Junio C Hamano <gitster@pobox.com>
+- We don't ship Python bits until a real foreign scm interface comes.
+
 * Mon Feb 04 2009 David J. Mellor <dmellor@whistlingcat.com>
 - fixed broken git help -w after renaming the git-core package to git.

Todd Zullinger· Jan 30, 2010, 19:47 UTC · re: Junio C Hamano · lore

Re: [RFH] rpm packaging failure

Junio C Hamano wrote:

> The files that are problematic are only infrastructure bits to
> support "remote helpers written in Python" (which we don't ship at
> all yet).

Ahh, I hadn't followed along closely enough to know that nothing which used these files was installed.

> And if the removal is the way to go for 1.7.0, is the following an
> Ok approach to do that removal (this is asking an RPM help again to
> Todd)?

Not shipping them if they aren't yet used/needed for anything other than folks working on remote helpers seems reasonable and the rm in the spec file should do the trick nicely. But I have to wonder why even bother installing them via make install if folks packaging via rpms, debs, etc. will all have to manually remove these files?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have never let my schooling interfere with my education.
    -- Mark Twain (1835-1910)

Junio C Hamano· Jan 30, 2010, 22:22 UTC · re: Todd Zullinger · lore

Re: [RFH] rpm packaging failure

Todd Zullinger <tmz@pobox.com> writes:

> Not shipping them if they aren't yet used/needed for anything other
> than folks working on remote helpers seems reasonable and the rm in
> the spec file should do the trick nicely.

Thanks.

To allow us to go forward a bit easier, I am planning to use the attached, as we would need some parts of it when we do start generating a separate package, I think.

-- >8 --
Subject: [PATCH] RPM packaging: don't include foreign-scm-helper bits yet

The files in /usr/lib/python* are only the support infrastructure for foreign scm interface yet to be written and/or shipped with git. Don't include them in the binary package (this will also free us from Python dependency).

When we ship with foreign scm interface, we will need to package these files with it in a separate subpackage, but we are not there yet.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git.spec.in |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/git.spec.in b/git.spec.in
index ab224f7..0a03108 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -98,6 +98,7 @@ BuildRequires:  perl(Error)
 Perl interface to Git
 
 %define path_settings ETC_GITCONFIG=/etc/gitconfig prefix=%{_prefix} mandir=%{_mandir} htmldir=%{_docdir}/%{name}-%{version}
+%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
 
 %prep
 %setup -q
@@ -112,6 +113,7 @@ rm -rf $RPM_BUILD_ROOT
 make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" DESTDIR=$RPM_BUILD_ROOT \
      %{path_settings} \
      INSTALLDIRS=vendor install %{!?_without_docs: install-doc}
+test ! -d $RPM_BUILD_ROOT%{python_sitelib} || rm -fr $RPM_BUILD_ROOT%{python_sitelib}
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
@@ -190,6 +192,9 @@ rm -rf $RPM_BUILD_ROOT
 # No files for you!
 
 %changelog
+* Sat Jan 30 2010 Junio C Hamano <gitster@pobox.com>
+- We don't ship Python bits until a real foreign scm interface comes.
+
 * Mon Feb 04 2009 David J. Mellor <dmellor@whistlingcat.com>
 - fixed broken git help -w after renaming the git-core package to git.

-- 
1.7.0.rc1.141.gd3fd2

Todd Zullinger· Jan 31, 2010, 04:12 UTC · re: Junio C Hamano · lore

Re: [RFH] rpm packaging failure

Junio C Hamano wrote:

> To allow us to go forward a bit easier, I am planning to use the
> attached, as we would need some parts of it when we do start
> generating a separate package, I think.

Sounds good.  One minor nit, below... ;)

>  %define path_settings ETC_GITCONFIG=/etc/gitconfig prefix=%{_prefix} mandir=%{_mandir} htmldir=%{_docdir}/%{name}-%{version}
> +%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}

It is probably better to use %global rather than %define here. The Fedora packaging guidelines now recommend this:

http://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define

The rationale is that %define only really lasts until the closing brace, while %global persists. A bug in rpm has masked this for a long time, but it now fixed in upstream rpm, which is packaged for Fedora's rawhide and possible other rpm-based distros. A bit more detail is available at:

https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html

(Which is linked, with an incorrect trailing '|' character from the Fedora guidelines URL above.)

Using %global should work on older rpm versions as well as current versions, so there should be no downside to using s/%define/%global in most cases.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The secret to success is knowing who to blame for your failures.
    -- Demotivators (www.despair.com)

Junio C Hamano· Jan 31, 2010, 19:18 UTC · re: Todd Zullinger · lore

Re: [RFH] rpm packaging failure

Todd Zullinger <tmz@pobox.com> writes:

> It is probably better to use %global rather than %define here.

Thanks; will fix.

David Aguilar· Jan 31, 2010, 23:14 UTC · re: Junio C Hamano · lore

Re: [RFH] rpm packaging failure

On Sat, Jan 30, 2010 at 02:22:03PM -0800, Junio C Hamano wrote:

Show 27 quoted lines

> Todd Zullinger <tmz@pobox.com> writes:
> 
> > Not shipping them if they aren't yet used/needed for anything other
> > than folks working on remote helpers seems reasonable and the rm in
> > the spec file should do the trick nicely.
> 
> Thanks.
> 
> To allow us to go forward a bit easier, I am planning to use the attached,
> as we would need some parts of it when we do start generating a separate
> package, I think.
> 
> -- >8 --
> Subject: [PATCH] RPM packaging: don't include foreign-scm-helper bits yet
> 
> The files in /usr/lib/python* are only the support infrastructure for
> foreign scm interface yet to be written and/or shipped with git.  Don't
> include them in the binary package (this will also free us from Python
> dependency).
> 
> When we ship with foreign scm interface, we will need to package these
> files with it in a separate subpackage, but we are not there yet.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  git.spec.in |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)

Apologies for the late response to this thread.

Would it be simpler to define NO_PYTHON when running make? We can always resurrect %python_sitelib when it is needed.

Here's what that looks like relative to master. I've tested this on fedora11.

On a slightly related note, I'm seeing this as well:

error: Installed (but unpackaged) file(s) found:
   /usr/lib/Git.pm

Maybe my setup is wanky?

-- >8 --
From 7fb05607633bc424fc29b645e6f4ee7e48371f94 Mon Sep 17 00:00:00 2001
From: David Aguilar <davvid@gmail.com>
Date: Sun, 31 Jan 2010 14:52:13 -0800
Subject: [PATCH] RPM packaging: Define NO_PYTHON to avoid Python dependency

We don't use the Python bits yet so we shouldn't require python to build. The %define used python to calculate %python_sitelib and thus incurred a build-time python dependency without specifying python in BuildRequires.

Signed-off-by: David Aguilar <davvid@gmail.com>
---
 git.spec.in |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/git.spec.in b/git.spec.in
index 0a03108..ae7edc6 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -98,7 +98,6 @@ BuildRequires:  perl(Error)
 Perl interface to Git
 
 %define path_settings ETC_GITCONFIG=/etc/gitconfig prefix=%{_prefix} mandir=%{_mandir} htmldir=%{_docdir}/%{name}-%{version}
-%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
 
 %prep
 %setup -q
@@ -106,14 +105,15 @@ Perl interface to Git
 %build
 make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" \
      %{path_settings} \
+     NO_PYTHON=NotYet \
      all %{!?_without_docs: doc}
 
 %install
 rm -rf $RPM_BUILD_ROOT
 make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" DESTDIR=$RPM_BUILD_ROOT \
      %{path_settings} \
+     NO_PYTHON=NotYet \
      INSTALLDIRS=vendor install %{!?_without_docs: install-doc}
-test ! -d $RPM_BUILD_ROOT%{python_sitelib} || rm -fr $RPM_BUILD_ROOT%{python_sitelib}
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
@@ -192,6 +192,9 @@ rm -rf $RPM_BUILD_ROOT
 # No files for you!
 
 %changelog
+* Sun Jan 31 2010 David Aguilar <davvid@gmail.com>
+- Define NO_PYTHON until we actually need the Python bits
+
 * Sat Jan 30 2010 Junio C Hamano <gitster@pobox.com>
 - We don't ship Python bits until a real foreign scm interface comes.

-- 
1.6.2.5

David Aguilar· Jan 31, 2010, 23:46 UTC · re: David Aguilar · lore

Re: [RFH] rpm packaging failure

On Sun, Jan 31, 2010 at 03:14:32PM -0800, David Aguilar wrote:

Show 36 quoted lines

> On Sat, Jan 30, 2010 at 02:22:03PM -0800, Junio C Hamano wrote:
> > Todd Zullinger <tmz@pobox.com> writes:
> > 
> > > Not shipping them if they aren't yet used/needed for anything other
> > > than folks working on remote helpers seems reasonable and the rm in
> > > the spec file should do the trick nicely.
> > 
> > Thanks.
> > 
> > To allow us to go forward a bit easier, I am planning to use the attached,
> > as we would need some parts of it when we do start generating a separate
> > package, I think.
> > 
> > -- >8 --
> > Subject: [PATCH] RPM packaging: don't include foreign-scm-helper bits yet
> > 
> > The files in /usr/lib/python* are only the support infrastructure for
> > foreign scm interface yet to be written and/or shipped with git.  Don't
> > include them in the binary package (this will also free us from Python
> > dependency).
> > 
> > When we ship with foreign scm interface, we will need to package these
> > files with it in a separate subpackage, but we are not there yet.
> > 
> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
> > ---
> >  git.spec.in |    5 +++++
> >  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> 
> Apologies for the late response to this thread.
> 
> Would it be simpler to define NO_PYTHON when running make?
> We can always resurrect %python_sitelib when it is needed.
> 
> Here's what that looks like relative to master.

I see you just pushed out a new master with the %define changes. Here's a rebased patch just in case.

-- >8 --
From ac09b94c332564cc7dde3c2f8961990098b5d4a0 Mon Sep 17 00:00:00 2001
From: David Aguilar <davvid@gmail.com>
Date: Sun, 31 Jan 2010 14:52:13 -0800
Subject: [PATCH] RPM packaging: Define NO_PYTHON to avoid Python dependency

Signed-off-by: David Aguilar <davvid@gmail.com>
---
 git.spec.in |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/git.spec.in b/git.spec.in
index ee74a5e..320829a 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -98,7 +98,6 @@ BuildRequires:  perl(Error)
 Perl interface to Git
 
 %define path_settings ETC_GITCONFIG=/etc/gitconfig prefix=%{_prefix} mandir=%{_mandir} htmldir=%{_docdir}/%{name}-%{version}
-%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
 
 %prep
 %setup -q
@@ -106,14 +105,15 @@ Perl interface to Git
 %build
 make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" \
      %{path_settings} \
+     NO_PYTHON=NotYet \
      all %{!?_without_docs: doc}
 
 %install
 rm -rf $RPM_BUILD_ROOT
 make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" DESTDIR=$RPM_BUILD_ROOT \
      %{path_settings} \
+     NO_PYTHON=NotYet \
      INSTALLDIRS=vendor install %{!?_without_docs: install-doc}
-test ! -d $RPM_BUILD_ROOT%{python_sitelib} || rm -fr $RPM_BUILD_ROOT%{python_sitelib}
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
 find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
@@ -192,6 +192,9 @@ rm -rf $RPM_BUILD_ROOT
 # No files for you!
 
 %changelog
+* Sun Jan 31 2010 David Aguilar <davvid@gmail.com>
+- Define NO_PYTHON until we actually need the Python bits.
+
 * Sun Jan 31 2010 Junio C Hamano <gitster@pobox.com>
 - Do not use %define inside %{!?...} construct.

-- 
1.7.0.rc1.7.gc0da5

Johan Herland· Jan 31, 2010, 00:06 UTC · re: Junio C Hamano · lore

Re: [RFH] rpm packaging failure

On Saturday 30 January 2010, Junio C Hamano wrote:

Show 15 quoted lines

> The files that are problematic are only infrastructure bits to support
> "remote helpers written in Python" (which we don't ship at all yet).
> 
> Once we start shipping real remote helpers, separating Python bits out
> into its own package would make a lot of sense.  People who want to use
> foreign scm helpers that happen to be written in Python would need it,
>  and all others don't.
> 
> But I suspect that a safer alternative at least for 1.7.0 would be to
> leave these files out altogether.  As I understand the current state, it
> is an unused but required package dependency on Python, a downside
>  without an upside.  Is it Ok with "remote helpers in Python" folks (I
>  think Sverre and Johan are principal parties), or did I miss some reason
>  that these need to be installed/installable, perhaps to support third
>  party packages that already exist?

AFAICS, there's no reason why these should be installed without anything actually using them. Although I defer to Sverre, who did the last work in this area.

...Johan

Sverre Rabbelier· Jan 31, 2010, 00:56 UTC · re: Johan Herland · lore

Re: [RFH] rpm packaging failure

Heya,

On Sun, Jan 31, 2010 at 01:06, Johan Herland <johan@herland.net> wrote:

> AFAICS, there's no reason why these should be installed without anything
> actually using them. Although I defer to Sverre, who did the last work in
> this area.

Agreed, no need to package the git_remote_helpers stuff yet in 1.7.0, since it'll be 1.7.1 at the earliest that we'll include git-remote-hg (and even that's assuming I'll find the time to work on it).

-- 
Cheers,

Sverre Rabbelier