[opensuse-packaging] Please criticise my spec file.

Paul Elliott

1 Sep 2007 1 Sep '07

23:22

Please find flaws and mistakes in the peless spec file for opensuse below: peless is ready to be translated, but currently has 0 translations. The build procedure creates a desktop file. How can I get peless into OpenSuSE? -------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome Name: peless Summary: Tabbed text browser Version: 1.156 Release: 19%{?dist} License: GPL Group: Productivity/Text/Utilities Source0: http://download.berlios.de/peless/%{name}-%{version}.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-build Packager: https://developer.berlios.de/projects/peless/ URL: https://developer.berlios.de/projects/peless/ Autoreqprov: on %{?suse_update_config:BuildRequires:autoconf automake libtool} BuildRequires: gtkmm24-devel, gconfmm-devel, boost-devel = 1.33.1, libsigc++2-devel, gettext, intltool, gcc-c++ %description Peless is a simple text file lister. It only displays files and never modifies them. It can display multiple files using a tabbed notebook, display international characters, and search the files for regular expressions or literal expressions. Users can choose the fonts used to display files. %prep %setup -q %{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}} %build CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ %configure --prefix=%{_prefix} --with-boost=/usr \ --with-dtcat=%{?DTCAT:%{DTCAT}}%{!?DTCAT:'Application;Utility;'} CCFLAGS=$RPM_OPT_FLAGS \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install-strip %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog NEWS README INTERNATIONALIZATION %{_bindir}/peless %{_datadir}/applications/%{name}.desktop %{_datadir}/pixmaps/%{name}.png %{_datadir}/pixmaps/%{name}.xpm %_mandir/man1/peless.1.* %changelog * Fri Aug 31 2007 Paul Elliott - 1.156-17 - add intltool, gcc-c++ * Wed Aug 29 2007 Paul Elliott - 1.156-5 - new Summary. * Sat Aug 25 2007 Paul Elliott - 1.156-3 - reorder changelog - replace /lib/ by /%{_lib}/ - must use %suse_update_config -f and %suse_update_libdir before configure with - every package - note that it might break the build of some packages, - so it must be tested (only remove it if it breaks), like this: - use # norootforbuild - group changes from Applications/Text to Productivity/Text/Utilities - change buildroot to opensuse preference. - add Autoreqprov: on * Wed Aug 1 2007 Paul Elliott - 1.156-3 - remove philo.txt from files distributed to end users. - And use https://developer.berlios.de/projects/peless/ as URL. * Tue Jul 24 2007 Paul Elliott - modify spec files on advise of fedora people. * Sun May 27 2007 Paul Elliott - update to satisfy fedora rules. * Sun Jan 22 2005 D. Scott Barninger - modify for gwdg.de repository -- Paul Elliott 1(512)837-1096 pelliott@io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

Attachments:

attachment.sig (application/pgp-signature — 189 bytes)

Show replies by date

Jan Engelhardt

2 Sep 2 Sep

00:01

On Sep 1 2007 16:22, Paul Elliott wrote:

...

Name: peless Summary: Tabbed text browser Version: 1.156 Release: 19%{?dist} License: GPL Group: Productivity/Text/Utilities Source0: http://download.berlios.de/peless/%{name}-%{version}.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-build Packager: https://developer.berlios.de/projects/peless/

Get rid of "Packager", "Vendor" and "Distribution"; they are provided by the build system (depends on the build system). Especially since you are the packager of the rpm, and not peless.

...

URL: https://developer.berlios.de/projects/peless/ Autoreqprov: on

Autoreqprov is the default already, so this line is redundant.

...

%{?suse_update_config:BuildRequires:autoconf automake libtool} BuildRequires: gtkmm24-devel, gconfmm-devel, boost-devel = 1.33.1, libsigc++2-devel, gettext, intltool, gcc-c++

%description Peless is a simple text file lister. It only displays files and never modifies them. It can display multiple files using a tabbed notebook, display international characters, and search the files for regular expressions or literal expressions. Users can choose the fonts used to display files.

%debug_package is missing. Well, people normally do not need it, but editing the specfile is something I would like to avoid, in case it seems necessary.

...

%prep %setup -q %{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}}

%build CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ %configure --prefix=%{_prefix} --with-boost=/usr \ --with-dtcat=%{?DTCAT:%{DTCAT}}%{!?DTCAT:'Application;Utility;'} CCFLAGS=$RPM_OPT_FLAGS \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ make %{?_smp_mflags}

Why is it necessary to set PKG_CONFIG_PATH again? pkgconfig is usually configured so that all the usual paths are scanned. CCFLAGS? That should probably be CXXFLAGS.

...

%install rm -rf $RPM_BUILD_ROOT

mkdir "$RPM_BUILD_ROOT" here

...

make DESTDIR=$RPM_BUILD_ROOT install-strip

Do not strip, this makes it impossible to build a debug package. Also, the build system will strip.

...

%clean rm -rf $RPM_BUILD_ROOT

%files %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog NEWS README INTERNATIONALIZATION %{_bindir}/peless %{_datadir}/applications/%{name}.desktop %{_datadir}/pixmaps/%{name}.png %{_datadir}/pixmaps/%{name}.xpm %_mandir/man1/peless.1.*

A lot of { } are superfluous. For example, %_datadir/pixmaps/%name.xpm would suffice. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Pascal Bleser

00:18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:

...

On Sep 1 2007 16:22, Paul Elliott wrote:

...
Name: peless Summary: Tabbed text browser Version: 1.156 Release: 19%{?dist} License: GPL Group: Productivity/Text/Utilities Source0: http://download.berlios.de/peless/%{name}-%{version}.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-build Packager: https://developer.berlios.de/projects/peless/

Get rid of "Packager", "Vendor" and "Distribution"; they are provided by the build system (depends on the build system). Especially since you are the packager of the rpm, and not peless.

Indeed. And if you're just using rpmbuild, you can set the packager like this: echo '%packager John Doe ' >> ~/.rpmmacros

...

...
URL: https://developer.berlios.de/projects/peless/ Autoreqprov: on

Autoreqprov is the default already, so this line is redundant.

...
%{?suse_update_config:BuildRequires:autoconf automake libtool} BuildRequires: gtkmm24-devel, gconfmm-devel, boost-devel = 1.33.1, libsigc++2-devel, gettext, intltool, gcc-c++

%description Peless is a simple text file lister. It only displays files and never modifies them. It can display multiple files using a tabbed notebook, display international characters, and search the files for regular expressions or literal expressions. Users can choose the fonts used to display files.

%debug_package is missing. Well, people normally do not need it, but editing the specfile is something I would like to avoid, in case it seems necessary.

You *must* add it (good practice). Furthermore, with %debug_package, rpmbuild will strip the binaries (and store the debug symbols into the -debuginfo subpackage).

...

...
%prep %setup -q %{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}}

Only use them if really needed as they involved autoreconf -fiv, which slows down the build considerably.

...

...
%build CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ %configure --prefix=%{_prefix} --with-boost=/usr \ --with-dtcat=%{?DTCAT:%{DTCAT}}%{!?DTCAT:'Application;Utility;'} CCFLAGS=$RPM_OPT_FLAGS \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ make %{?_smp_mflags}

Why is it necessary to set PKG_CONFIG_PATH again? pkgconfig is usually configured so that all the usual paths are scanned.

Right, those additions above are useless. Also, using %{_prefix}/%{_lib} and %{_prefix}/share is wrong (or rather, not always correct). Use %{_libdir} and %{_datadir} instead (respectively).

...

CCFLAGS? That should probably be CXXFLAGS.

...
%install rm -rf $RPM_BUILD_ROOT

mkdir "$RPM_BUILD_ROOT" here

Neither. no need to mkdir it. Do NOT use rm -rf $RPM_BUILD_ROOT because it potentially creates a race condition. Just remove that line.

...

...
make DESTDIR=$RPM_BUILD_ROOT install-strip

Do not strip, this makes it impossible to build a debug package. Also, the build system will strip.

Exactly, or %debug_package takes care of it. Also, rather use the macro %makeinstall, which does this: %__make DESTDIR="%{buildroot}" install

...

...
%clean rm -rf $RPM_BUILD_ROOT

%__rm -rf "%{buildroot}" (but I'm being pedantic here ;D)

...

...
%files %defattr(-, root, root) %doc AUTHORS COPYING ChangeLog NEWS README INTERNATIONALIZATION %{_bindir}/peless %{_datadir}/applications/%{name}.desktop %{_datadir}/pixmaps/%{name}.png %{_datadir}/pixmaps/%{name}.xpm %_mandir/man1/peless.1.*

A lot of { } are superfluous. For example, %_datadir/pixmaps/%name.xpm would suffice.

Yes and no. Personally, I like to use %{} for "variables" and just % for "commands". It's a matter of taste and style. Wouldn't say they're superfluous as they certainly don't harm readability. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFG2eVRr3NMWliFcXcRAvS5AJ9SwZdBSTP99VPwgouxG7LEpDpO3wCfeH1G eIVmPwMk3JsD/ijmop+MGFU= =3xbn -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Jan Engelhardt

13:45

On Sep 2 2007 00:18, Pascal Bleser wrote:

...

...
On Sep 1 2007 16:22, Paul Elliott wrote:

...
Name: peless Summary: Tabbed text browser Version: 1.156 Release: 19%{?dist} License: GPL Group: Productivity/Text/Utilities Source0: http://download.berlios.de/peless/%{name}-%{version}.tar.bz2 BuildRoot: %{_tmppath}/%{name}-%{version}-build Packager: https://developer.berlios.de/projects/peless/

Get rid of "Packager", "Vendor" and "Distribution"; they are provided by the build system (depends on the build system). Especially since you are the packager of the rpm, and not peless.

Indeed.

(packman could really adhere to that too)

...

And if you're just using rpmbuild, you can set the packager like this: echo '%packager John Doe ' >> ~/.rpmmacros

And if you are using lbuild, oh well, you need patches first.

...

...
%debug_package is missing. Well, people normally do not need it, but editing the specfile is something I would like to avoid, in case it seems necessary.

You *must* add it (good practice).

It's not done for kernel-<flavor>, and there, it's a good thing not do so :)

...

Furthermore, with %debug_package, rpmbuild will strip the binaries (and store the debug symbols into the -debuginfo subpackage).

Someone explain me the Fedora idiocy to implicitly add %debug_package on every package...

...

...
...
%install rm -rf $RPM_BUILD_ROOT

mkdir "$RPM_BUILD_ROOT" here

Neither. no need to mkdir it.

This is 'needed' to avoid races outside lbuild. I can't find it, but it was on lists.opensuse.org once.

...

Do NOT use rm -rf $RPM_BUILD_ROOT because it potentially creates a race condition.

Explain.

...

...
Do not strip, this makes it impossible to build a debug package. Also, the build system will strip.

Exactly, or %debug_package takes care of it.

Also, rather use the macro %makeinstall, which does this: %__make DESTDIR="%{buildroot}" install

So what's the point of all the macros..

...

...
...
%clean rm -rf $RPM_BUILD_ROOT

%__rm -rf "%{buildroot}" (but I'm being pedantic here ;D)

Yeah, sounds really redundant this %__make and %__rm. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Marcus Hüwe

18:44

On 2007-09-02 13:45:06 +0200, Jan Engelhardt wrote:

...

On Sep 2 2007 00:18, Pascal Bleser wrote:

...
Do NOT use rm -rf $RPM_BUILD_ROOT because it potentially creates a race condition.

Explain.

See http://lists.opensuse.org/opensuse-packaging/2007-02/msg00005.html Marcus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Cristian Rodriguez

03:18

Paul Elliott escribió:

...

-------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome

uh ho. GNOME has moved to /usr

...

%{?suse_update_config:BuildRequires:autoconf automake libtool} %{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}}

If you really need what those macros do, create a patch instead.

...

%install rm -rf $RPM_BUILD_ROOT

nope. you should not do that.

...

%changelog * Fri Aug 31 2007 Paul Elliott - 1.156-17 - add intltool, gcc-c++

use the changes file instead. -- Cristian Rodríguez R. SUSE R&D "You don't have to burn books to destroy a culture. Just get people to stop reading them." --Ray Bradbury --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michel Salim

04:38

On 01/09/07, Cristian Rodriguez wrote:

...

Paul Elliott escribió:

...
-------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome

uh ho. GNOME has moved to /usr

%if %{?suse_version} %if %{suse_version} <= 1020 %define _prefix /opt/gnome %endif %endif should do nicely. Regards, -- Michel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Marcus Rueckert

05:19

On 2007-09-01 22:38:55 -0400, Michel Salim wrote:

...

On 01/09/07, Cristian Rodriguez wrote:

...
Paul Elliott escribió:

...
-------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome

uh ho. GNOME has moved to /usr

%if %{?suse_version} %if %{suse_version} <= 1020 %define _prefix /opt/gnome %endif %endif

should do nicely.

%if 0%{?suse_version} < 1030 %define _prefix /opt/gnome %endif -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michel Salim

07:52

On 01/09/07, Marcus Rueckert wrote:

...

On 2007-09-01 22:38:55 -0400, Michel Salim wrote:

...
On 01/09/07, Cristian Rodriguez wrote:

...
Paul Elliott escribió:

...
-------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome

uh ho. GNOME has moved to /usr

%if %{?suse_version} %if %{suse_version} <= 1020 %define _prefix /opt/gnome %endif %endif

should do nicely.

%if 0%{?suse_version} < 1030 %define _prefix /opt/gnome %endif

This will make the spec openSUSE-specific: if suse_version is not defined, you'll get %if 0 < 1030 which will be bad if the spec is used to build packages for, say, Fedora or Mandriva as well. the %if %suse_version will guard against that, so _prefix is only overridden if 1. we are on openSUSE 2. it is a release < 10.3 <= 1020 could be replaced with < 1030, both are OK since I believe no SUSE release has suse_version set to anything between 1020 and 1030. Regards, -- Michel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Marcus Rueckert

08:20

On 2007-09-02 01:52:58 -0400, Michel Salim wrote:

...

Date: Sun, 2 Sep 2007 01:52:58 -0400 From: Michel Salim Subject: Re: [opensuse-packaging] Please criticise my spec file. To: Marcus Rueckert Cc: Cristian Rodriguez , opensuse-packaging@opensuse.org X-DSPAM-Result: Whitelisted X-DSPAM-Confidence: 0.9905 X-DSPAM-Probability: 0.0000

On 01/09/07, Marcus Rueckert wrote:

...
On 2007-09-01 22:38:55 -0400, Michel Salim wrote:

...
On 01/09/07, Cristian Rodriguez wrote:

...
Paul Elliott escribió:

...
-------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome

uh ho. GNOME has moved to /usr

%if %{?suse_version} %if %{suse_version} <= 1020 %define _prefix /opt/gnome %endif %endif

should do nicely.

%if 0%{?suse_version} < 1030 %define _prefix /opt/gnome %endif

This will make the spec openSUSE-specific: if suse_version is not defined, you'll get

%if 0 < 1030

which will be bad if the spec is used to build packages for, say, Fedora or Mandriva as well. the %if %suse_version will guard against that, so _prefix is only overridden if 1. we are on openSUSE 2. it is a release < 10.3

<= 1020 could be replaced with < 1030, both are OK since I believe no SUSE release has suse_version set to anything between 1020 and 1030.

so lets take %if ! 0%{?suse_version} > 1020 darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stanislav Brabec

4 Sep 4 Sep

16:49

Marcus Rueckert wrote:

...

%if 0%{?suse_version} < 1030 %define _prefix /opt/gnome %endif

Insufficient. If you want to use %configure, you have to redefine all used paths (_bindir, _datadir and so on). You also may use following trick: %define _prefix %(pkg-config --variable=prefix libgnome-2.0) %define _libdir %(pkg-config --variable=libdir libgnome-2.0) ... Instead of "libgnome-2.0" you can use package of your choice. Not all standard variables are defined in all packages. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Marcus Rueckert

16:53

On 2007-09-04 16:49:05 +0200, Stanislav Brabec wrote:

...

Marcus Rueckert wrote:

...
%if 0%{?suse_version} < 1030 %define _prefix /opt/gnome %endif

Insufficient. If you want to use %configure, you have to redefine all used paths (_bindir, _datadir and so on).

You also may use following trick: %define _prefix %(pkg-config --variable=prefix libgnome-2.0) %define _libdir %(pkg-config --variable=libdir libgnome-2.0) ...

Instead of "libgnome-2.0" you can use package of your choice. Not all standard variables are defined in all packages.

afaik all other variables are defined relative to _prefix. so just changing _prefix should be sufficient no? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stanislav Brabec

17:33

Marcus Rueckert wrote:

...

On 2007-09-04 16:49:05 +0200, Stanislav Brabec wrote:

...
Marcus Rueckert wrote:

...
%if 0%{?suse_version} < 1030 %define _prefix /opt/gnome %endif

Insufficient. If you want to use %configure, you have to redefine all used paths (_bindir, _datadir and so on).

My mistake. Most paths are really changes automatically.

...

...
You also may use following trick: %define _prefix %(pkg-config --variable=prefix libgnome-2.0) %define _libdir %(pkg-config --variable=libdir libgnome-2.0) ...

Instead of "libgnome-2.0" you can use package of your choice. Not all standard variables are defined in all packages.

afaik all other variables are defined relative to _prefix.

Yes, you are nearly true. Most other variables are defined relative to _prefix and correctly expanded even after changing it. Exceptions are: sysconfdir and _localstatedir. _libexecdir is prefixed to a bad value in all cases.

...

so just changing _prefix should be sufficient no?

_prefix, _sysconfdir, _localstatedir and again _libexecdir. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michel Salim

22:47

On 04/09/07, Marcus Rueckert wrote:

...

On 2007-09-04 16:49:05 +0200, Stanislav Brabec wrote:

...
Marcus Rueckert wrote:

...
%if 0%{?suse_version} < 1030 %define _prefix /opt/gnome %endif

Insufficient. If you want to use %configure, you have to redefine all used paths (_bindir, _datadir and so on).

You also may use following trick: %define _prefix %(pkg-config --variable=prefix libgnome-2.0) %define _libdir %(pkg-config --variable=libdir libgnome-2.0) ...

Instead of "libgnome-2.0" you can use package of your choice. Not all standard variables are defined in all packages.

afaik all other variables are defined relative to _prefix. so just changing _prefix should be sufficient no?

Yes; I've tried not overriding _libdir, etc. and it has no effect. Depending on the files the package install, though, you might still have to redefine _sysconfdir : on openSUSE 10.2 and below it's /etc%{_prefix} rather than /etc . -- Michel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Jan Engelhardt

2 Sep 2 Sep

13:46

On Sep 1 2007 21:18, Cristian Rodriguez wrote:

...

Paul Elliott escribió:

...
-------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome

uh ho. GNOME has moved to /usr

And KDE has not. I really question the weirdo move (but only for the .so files) to /usr. And since people already use pkg-config, having the rest of the stuff in /usr/include and such has already become a non-requirement in the past. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

15:24

* Jan Engelhardt [2007-09-02 13:46]:

...

On Sep 1 2007 21:18, Cristian Rodriguez wrote:

...
Paul Elliott escribió:

...
-------------------cut here with a chainsaw-------------------- # norootforbuild %define _prefix /opt/gnome

uh ho. GNOME has moved to /usr

And KDE has not.

But KDE4. So it's only a matter of time.

...

I really question the weirdo move (but only for the .so files) to /usr.

That's not the question here. 10.3 has moved GNOME to /usr, and additional packages have to honor this (or do you really want a full /opt/gnome tree only for one addon package?). Thanks, Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Jan Engelhardt

16:39

On Sep 2 2007 15:24, Bernhard Walle wrote:

...

...
I really question the weirdo move (but only for the .so files) to /usr.

That's not the question here. 10.3 has moved GNOME to /usr, and additional packages have to honor this (or do you really want a full /opt/gnome tree only for one addon package?).

Define 'full'. AFAICS, it does not matter where <this or that> is located. Dynamic libraries are found through /etc/ld.so.conf, devel/include files through pkgconfig, binaries through $PATH (/etc/profile*), data files, oh well, guess you have a point for the last item. Did I miss something? Jan -- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Bernhard Walle

21:23

* Jan Engelhardt [2007-09-02 16:39]:

...

On Sep 2 2007 15:24, Bernhard Walle wrote:

...
...
I really question the weirdo move (but only for the .so files) to /usr.

That's not the question here. 10.3 has moved GNOME to /usr, and additional packages have to honor this (or do you really want a full /opt/gnome tree only for one addon package?).

Define 'full'.

All top-level directories. /opt/gnome/bin /opt/gnome/share /opt/gnome/lib{,64} That only for some addon packages and the basic GNOME in /usr? What's the benefit beside of confusing the user? What's if /opt/gnome/bin is not in $PATH any more after a transitional phase? Same for the linker cache. /opt/gnome will be gone, and the same for /opt/kde after KDE4 is stable. Thanks, Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Paul Elliott

4 Sep 4 Sep

04:38

On Sat, Sep 01, 2007 at 09:18:03PM -0400, Cristian Rodriguez wrote:

...

Paul Elliott escribió:

...
%{?suse_update_config:BuildRequires:autoconf automake libtool} %{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}}

If you really need what those macros do, create a patch instead.

I added these because of the Packman guidelines for Biarch/AMD64. http://wiki.links2linux.de/en/index.php/PackMan:PackagingConventions#Biarch....

...

Biarch/AMD64 Various issues related to building on biarch/amd64 architecture: must use %suse_update_config -f and %suse_update_libdir before configure with every package - note that it might break the build of some packages, so it must be tested (only remove it if it breaks), like this:

...

... %{?suse_update_config:BuildRequires:autoconf automake libtool} ... %prep %setup -q ..... %{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}}

Why did the packman people say this, why are they wrong, and what should I do instead? -- Paul Elliott 1(512)837-1096 pelliott@io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

Stanislav Brabec

17:03

Paul Elliott wrote:

...

http://wiki.links2linux.de/en/index.php/PackMan:PackagingConventions#Biarch....

...
Biarch/AMD64 Various issues related to building on biarch/amd64 architecture: must use %suse_update_config -f and %suse_update_libdir before configure with every package - note that it might break the build of some packages, so it must be tested (only remove it if it breaks), like this:

...
... %{?suse_update_config:BuildRequires:autoconf automake libtool} ... %prep %setup -q ..... %{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}}

Why did the packman people say this, why are they wrong, and what should I do instead?

In history, there was a long period, when upstream autotools were not able to detect x86_64 and even longer period (not finished yet) when programmers learned, that $(libdir) might be different from $(prefix)/lib. This was the easiest way to make it working. Correct is: 1. Package should behave correctly. 2. If it does not, try autoreconf. If it helps, ask authors to use newer autotools chain. 3. If it does not help, create a patch and send it upstream. If you are lazy: 1. Package should behave correctly. 2. If it does not, call suse_update* hacks and hope that it fixed it. Incorrect is: 1. Call suse_update* hacks every time and hope that it did not break it. 2. If it breaks, don't call it. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Stanislav Brabec

16:43

Paul Elliott wrote:

...

Autoreqprov: on AFAIK it is Automatically on in new distros.

...

%{?suse_update_libdir:%{suse_update_libdir}} %{?suse_update_config:%{suse_update_config -f}}

I personally prefer autoreconf -f -i in %build phase instead, if is is doable. It prevents bad detection of uncommon platforms or new systems not supported in authors automake.

...

CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS" \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ %configure --prefix=%{_prefix}

This PKG_CONFIG_PATH stuff will probably break multi-prefix systems (SuSE <= 10.2). For other systems, it is only obsolete. %configure already includes setting of CFLAGS, CXXFLAGS, prefix, libdir and other dirs except libexecdir, which is set incorrectly by RPM.

...

CCFLAGS=$RPM_OPT_FLAGS \ PKG_CONFIG_PATH=%{_prefix}/%{_lib}/pkgconfig:%{_prefix}/share/pkgconfig \ make %{?_smp_mflags}

If sources are not broken, both CFLAGS and PKG_CONFIG_PATH are obsolete here.

...

rm -rf $RPM_BUILD_ROOT

At least in SuSE, don't use it, see other mails. For other distros, check its documentation.

...

make DESTDIR=$RPM_BUILD_ROOT install-strip

install-strip effectively kills %debug_package. Use plain install, if you want to provide debug information. In suse %makeinstall does the work well (not in other distros, where it still not uses DESTDIR). -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

JP Rosevear

18:24

On Sat, 2007-09-01 at 16:22 -0500, Paul Elliott wrote:

...

Please find flaws and mistakes in the peless spec file for opensuse below: peless is ready to be translated, but currently has 0 translations. The build procedure creates a desktop file.

How can I get peless into OpenSuSE?

For anything GNOME related, we'll be happy to take it into the main GNOME:Community repository when its ready to go. Join the opensuse-gnome@opensuse.org mailing list and the #opensuse-gnome irc channel if you want to propose it. After that we can discuss getting it in for the next openSUSE version. -JP -- JP Rosevear Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

6081

Age (days ago)

6084

Last active (days ago)

List overview

Download

21 comments

10 participants

participants (10)

Bernhard Walle
Cristian Rodriguez
Jan Engelhardt
JP Rosevear
Marcus Hüwe
Marcus Rueckert
Michel Salim
Pascal Bleser
Paul Elliott
Stanislav Brabec