Attention: Lots of SUSE packages are built incorrectly
---------- Forwarded message ---------- From: Alexey Eremenko <al4321@gmail.com> Date: Apr 19, 2006 4:48 PM Subject: Attention: Lots of SUSE packages are packaged incorrect To: suse-linux-e@suse.com Hi all ! I would like to discuss with the SUSE community one mistake commonly done by SUSE packagers: more specifically - the RPM architecture in SUSE. I have found a LOT of noarch packages built for the i586 architecture in SUSE Linux 10.0. I propose to people to identify those packages, that should be made "noarch" but for some obscure reason are not. Most packages that were built in the incorrect way were documentation, but some others were written in Interpreted languages. (like Python) One example of interpreted language package that is i586 but should be noarch is : "eric" IDE I have not dive too deep, but I'm sure there are other examples. The other incorrectly packaged packages are docs - quick search returns me: linux:/mnt/cdrom/suse/i586 # ls | grep doc | sort | cat -n 1 apache2-doc-2.0.54-10.i586.rpm 2 atk-doc-1.10.3-2.i586.rpm 3 at-spi-doc-1.6.6-2.i586.rpm 4 bind-doc-9.3.1-8.i586.rpm 5 cvs-doc-1.12.12-4.i586.rpm 6 docbook2x-0.8.5-5.i586.rpm 7 gconf2-doc-2.12.0-2.i586.rpm 8 glib2-doc-2.8.1-3.i586.rpm 9 gnome-doc-utils-0.4.0-2.i586.rpm 10 gnome-panel-doc-2.12.0-5.i586.rpm 11 gnome-vfs2-doc-2.12.0-9.i586.rpm 12 gtk2-doc-2.8.3-4.i586.rpm 13 gtksourceview-doc-1.4.1-2.i586.rpm 14 kdelibs3-doc-3.4.2-24.i586.rpm 15 krb5-doc-1.4.1-5.i586.rpm 16 libbonobo-doc-2.10.1-3.i586.rpm 17 libbonoboui-doc-2.10.1-3.i586.rpm 18 libglade2-doc-2.5.1-9.i586.rpm 19 libgnomecanvas-doc-2.12.0-2.i586.rpm 20 libgnome-doc-2.12.0.1-2.i586.rpm 21 libgnomeprint-doc-2.12.0-4.i586.rpm 22 libgnomeprintui-doc-2.12.0-3.i586.rpm 23 libgnomeui-doc-2.12.0-3.i586.rpm 24 libgsf-doc-1.12.1-3.i586.rpm 25 libicu-doc-3.4-3.i586.rpm 26 libreadline-java-javadoc-0.8.0-11.i586.rpm 27 lilypond-documentation-2.6.3-2.i586.rpm 28 python-twisted-doc-2.0.0-2.i586.rpm 29 qt3-devel-doc-3.3.4-28.i586.rpm 30 samba-doc-3.0.20-4.i586.rpm 31 xen-doc-html-3.0_6715-2.i586.rpm 32 xen-doc-pdf-3.0_6715-2.i586.rpm 33 xen-doc-ps-3.0_6715-2.i586.rpm now, 33 doc packages are i386 ? And, of course all of them contain binaries, huh! :) Look, it wastes time & server space to get noarch packges built for different platforms. Why is this ? OS: SUSE Linux 10.0 -Alexey Eremenko. 19.04.2006.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexey Eremenko wrote:
---------- Forwarded message ---------- From: Alexey Eremenko <al4321@gmail.com> Date: Apr 19, 2006 4:48 PM Subject: Attention: Lots of SUSE packages are packaged incorrect To: suse-linux-e@suse.com I would like to discuss with the SUSE community one mistake commonly done by SUSE packagers: more specifically - the RPM architecture in SUSE. I have found a LOT of noarch packages built for the i586 architecture in SUSE Linux 10.0. I propose to people to identify those packages, that should be made "noarch" but for some obscure reason are not.
Let me guess, python and perl packages ? :)
Most packages that were built in the incorrect way were documentation, but some others were written in Interpreted languages. (like Python) One example of interpreted language package that is i586 but should be noarch is : "eric" IDE I have not dive too deep, but I'm sure there are other examples. The other incorrectly packaged packages are docs - quick search returns me:
Indeed you have not "dive too deep". While most of those packages only contain interpreted bytecode (or plain source), 1) some also contain compiled code (e.g. _xxx.so or .pyo for Python) 2) they are installed into an arch-specific subdirectory, namely /usr/lib/python/site-packages on i586, and /usr/lib64/python/site-packages on x86_64 Same goes for Perl. That's the reason why they are arch-specific. And if you ask yourself (or us) "but why ?", it's because those directories may also contain compiled code.
linux:/mnt/cdrom/suse/i586 # ls | grep doc | sort | cat -n 1 apache2-doc-2.0.54-10.i586.rpm 2 atk-doc-1.10.3-2.i586.rpm
And that's because with RPM, you can only define the architecture for the whole spec file, which includes the main package and all the subpackages. You cannot define a subpackage (e.g. foo-doc) to have another architecture than the main package (foo). ...
now, 33 doc packages are i386 ? And, of course all of them contain binaries, huh! :) Look, it wastes time & server space to get noarch packges built for different platforms.
Why is this ?
Please buy yourself a clue before starting to flame. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFESB5Dr3NMWliFcXcRAvsWAKCaSeZxFQI0CaAfK4DYUEA2wAgmxwCgumeK nJgmvV1JE2dpVaPvXXuZ/y0= =cYjV -----END PGP SIGNATURE-----
Sorry, but isn't there a way to make two different specfiles - say one for apache and second for apache doc ? This could save some space on multi-arch servers.
On 2006-04-20 22:00:17 -0200, Alexey Eremenko wrote:
Sorry, but isn't there a way to make two different specfiles - say one for apache and second for apache doc ?
This could save some space on multi-arch servers.
see my email. and if you want to save space. dont install both doc packages ;) you have that choice. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On 2006-04-20 21:28:37 -0200, Alexey Eremenko wrote:
I would like to discuss with the SUSE community one mistake commonly done by SUSE packagers: more specifically - the RPM architecture in SUSE.
I have found a LOT of noarch packages built for the i586 architecture in SUSE Linux 10.0.
I propose to people to identify those packages, that should be made "noarch" but for some obscure reason are not.
Most packages that were built in the incorrect way were documentation, but some others were written in Interpreted languages. (like Python)
One example of interpreted language package that is i586 but should be noarch is : "eric" IDE
I have not dive too deep, but I'm sure there are other examples.
The other incorrectly packaged packages are docs - quick search returns me:
linux:/mnt/cdrom/suse/i586 # ls | grep doc | sort | cat -n
you should note that you cant have different build architectures inside a spec file. so if you build bind. and split of the docs from this package, then the docs will be arch too. sad but true. regarding eric. this is a python package. there is no /usr/share/python. for pure python packages. so you have a eric for i386 which goes into /usr/lib/python2.4 and a x86_64 which goes into /usr/lib64/python2.4. that should explain the "weirdness" for you. of course you could argue: write 2 spec files to generate the noarch packages. but this increases the workload. stuff like /usr/share/python or /usr/share/ruby might be interesting. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus Rueckert wrote: ...
of course you could argue: write 2 spec files to generate the noarch packages. but this increases the workload.
stuff like /usr/share/python or /usr/share/ruby might be interesting.
Although, as far as Python is concerned, you also have .so's under /usr/lib[64]/python/site-packages/ It would be slightly more complicated than that I'm afraid :\ cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFESCQbr3NMWliFcXcRAvCiAKCHXQRcW+Kbio41CYIxXpm+gJ8RbQCfb2BI CMOJbeTRMkfqDHPLV+res3Q= =Y2Fk -----END PGP SIGNATURE-----
On 2006-04-21 02:15:23 +0200, Pascal Bleser wrote:
stuff like /usr/share/python or /usr/share/ruby might be interesting.
Although, as far as Python is concerned, you also have .so's under /usr/lib[64]/python/site-packages/
ruby has so files too. :) but pure ruby/python packages could be installed to /usr/share. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
stuff like /usr/share/python or /usr/share/ruby might be interesting.
Yes, that is a good idea, but the major problem with this idea is that upstream dislikes it: http://python.org/sf/588756 Debian does it anyway, but my opinion is: Don't do it as long as the discussion is not finished upstream. Otherwise we risk that SUSE users are excluded from upstream mailing list support. (Some developers have a tendency to recommend things like "remove all distro supplied stuff and compile from source" if they see something "unusual".) -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
On 2006-04-21 03:21:20 +0200, andreas.hanke@gmx-topmail.de wrote:
stuff like /usr/share/python or /usr/share/ruby might be interesting.
Yes, that is a good idea, but the major problem with this idea is that upstream dislikes it:
Debian does it anyway, but my opinion is: Don't do it as long as the discussion is not finished upstream. Otherwise we risk that SUSE users are excluded from upstream mailing list support. (Some developers have a tendency to recommend things like "remove all distro supplied stuff and compile from source" if they see something "unusual".)
the sad point is ... upstream often doesnt really care about distribution issues. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
After all - there are symlinks to satisfy both :)
participants (5)
-
Alexey Eremenko -
andreas.hanke＠gmx-topmail.de -
Marcus Rueckert -
Marcus Rueckert -
Pascal Bleser