[RFH] rpm packaging failure

[RFH] rpm packaging failure

[Junio C Hamano]

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

Re: [RFH] rpm packaging failure

[Todd Zullinger]

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.

Re: [RFH] rpm packaging failure

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

> 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.
 

Re: [RFH] rpm packaging failure

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

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)


[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]

Re: [RFH] rpm packaging failure

[Junio C Hamano]

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

Re: [RFH] rpm packaging failure

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

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)


[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]

Re: [RFH] rpm packaging failure

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

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

Thanks; will fix.

Re: [RFH] rpm packaging failure

[David Aguilar]

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'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

Re: [RFH] rpm packaging failure

[David Aguilar]

On Sun, Jan 31, 2010 at 03:14:32PM -0800, David Aguilar wrote:
> 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

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 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

Re: [RFH] rpm packaging failure

[Johan Herland]

On Saturday 30 January 2010, 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).
> 
> 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

Re: [RFH] rpm packaging failure

[Sverre Rabbelier]

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