From abo at root.snowtree.se Sat Jan 2 14:47:04 2010
From: abo at root.snowtree.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sat, 02 Jan 2010 15:47:04 +0100
Subject: [Fedora-packaging] Suggested updated Java guidelines
Message-ID: <1262443624.6749.1609.camel@localhost>
Hi,
I submitted a review for java-gnome and working on that made me think
the Java guidelines needs work, so here's a suggested update:
https://fedoraproject.org/wiki/User:Abo/JavaPackagingDraftUpdate
=== Changes ===
Removed some occurances of a Unicode control character that didn't seem
to belong there.
Fixed formatting of the text under "Jar file naming".
Hopefully clarified the text under "Directory structure".
Changed some occuranced of "%{_xxx}" into
"%{_xxx}".
Changed -javadoc Group tag from "Development Documentation" to
"Documentation".
Mostly rewrote the section on JNI packaging. (See wiki.)
Removed this text:
The %{_jnidir} rpm macro defines the main JNI jar
repository. Like %{_javadir} it is declined in
-ext and -x.y.z variants. It follows
exactly the same rules as the %{_javadir}-derived
tree structure, except that it hosts JAR files that use JNI.
%{_jnidir} usually expands into
/usr/lib/java.
It seems to belong to the "The plan is to eventually..." part, but I
don't really understand it. Explain and I'll add something back. :)
Partially rewrote the section on prebuilt binaries and the suggested %
prep section. (See wiki.)
/abo
From jussilehtola at fedoraproject.org Sat Jan 2 21:33:19 2010
From: jussilehtola at fedoraproject.org (Jussi Lehtola)
Date: Sat, 02 Jan 2010 23:33:19 +0200
Subject: [Fedora-packaging] Suggested specification to changelog guidelines
Message-ID: <1262467999.21612.1.camel@localhost>
Hi,
I'd like to suggest
https://fedoraproject.org/wiki/PackagingDrafts/ChangelogStyles
for discussion. Now some packages mix the styles, which IMHO is bad
style.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola at fedoraproject.org
From tgl at redhat.com Sat Jan 2 22:06:18 2010
From: tgl at redhat.com (Tom Lane)
Date: Sat, 02 Jan 2010 17:06:18 -0500
Subject: [Fedora-packaging] Suggested specification to changelog
guidelines
In-Reply-To: <1262467999.21612.1.camel@localhost>
References: <1262467999.21612.1.camel@localhost>
Message-ID: <19532.1262469978@sss.pgh.pa.us>
Jussi Lehtola writes:
> I'd like to suggest
> https://fedoraproject.org/wiki/PackagingDrafts/ChangelogStyles
> for discussion.
Not a good idea. Different people do this differently, and
since some of those people are doing bulk rebuilds, there's no
way to guarantee that exactly the same format will be followed
in all the historical entries in a changelog. Or do you envision
that people will actually retroactively change old log entries
to match their preferred format? Now *that* would be a bad idea.
regards, tom lane
From jussilehtola at fedoraproject.org Sat Jan 2 22:10:14 2010
From: jussilehtola at fedoraproject.org (Jussi Lehtola)
Date: Sun, 03 Jan 2010 00:10:14 +0200
Subject: [Fedora-packaging] Suggested specification to changelog
guidelines
In-Reply-To: <19532.1262469978@sss.pgh.pa.us>
References: <1262467999.21612.1.camel@localhost>
<19532.1262469978@sss.pgh.pa.us>
Message-ID: <1262470214.21612.11.camel@localhost>
On Sat, 2010-01-02 at 17:06 -0500, Tom Lane wrote:
> Jussi Lehtola writes:
> > I'd like to suggest
> > https://fedoraproject.org/wiki/PackagingDrafts/ChangelogStyles
> > for discussion.
>
> Not a good idea. Different people do this differently, and
> since some of those people are doing bulk rebuilds, there's no
> way to guarantee that exactly the same format will be followed
> in all the historical entries in a changelog. Or do you envision
> that people will actually retroactively change old log entries
> to match their preferred format? Now *that* would be a bad idea.
I thought that the mass bump scripts checked which format has been used.
I'm not familiar with them, though.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola at fedoraproject.org
From tgl at redhat.com Sat Jan 2 22:24:42 2010
From: tgl at redhat.com (Tom Lane)
Date: Sat, 02 Jan 2010 17:24:42 -0500
Subject: [Fedora-packaging] Suggested specification to changelog
guidelines
In-Reply-To: <1262470214.21612.11.camel@localhost>
References: <1262467999.21612.1.camel@localhost>
<19532.1262469978@sss.pgh.pa.us>
<1262470214.21612.11.camel@localhost>
Message-ID: <19856.1262471082@sss.pgh.pa.us>
Jussi Lehtola writes:
> On Sat, 2010-01-02 at 17:06 -0500, Tom Lane wrote:
>> Not a good idea. Different people do this differently, and
>> since some of those people are doing bulk rebuilds, there's no
>> way to guarantee that exactly the same format will be followed
>> in all the historical entries in a changelog. Or do you envision
>> that people will actually retroactively change old log entries
>> to match their preferred format? Now *that* would be a bad idea.
> I thought that the mass bump scripts checked which format has been used.
The ones that have hit my packages don't appear to have paid any
attention to what was being used before. In any case, different
maintainers might have responsibility for the same package over time.
Your proposal would require a maintainer to continue with a style he
doesn't prefer, or retroactively edit the old entries, neither of which
seems like a good idea to me. If there were actually any significant
benefit to having One True Style, the guidelines would have mandated
one style. Observe that they did not.
regards, tom lane
From mschwendt at gmail.com Tue Jan 5 15:08:21 2010
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 5 Jan 2010 16:08:21 +0100
Subject: [Fedora-packaging] Our static Libraries packaging guidelines once
more
In-Reply-To: <20091207193525.71338163@gmail.com>
References: <20091205181941.600ac00f@gmail.com> <20091205180049.GF4179@free.fr>
<20091205191847.2c9c6aa1@gmail.com> <4B1CFFEE.7020306@jcomserv.net>
<20091207193525.71338163@gmail.com>
Message-ID: <20100105160821.59fbef0b@gmail.com>
How much do we adhere to our Packaging Guidelines for static libraries?
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries
What had started with a few Yum queries for corner-cases (see
https://www.redhat.com/archives/fedora-packaging/2009-December/msg00012.html )
has continued with another remote repository checking script:
[...]
Target distribution:
rawhide
Reading repository metadata...
Misnamed -devel/-static packages:
db4-devel-static from db4-4.8.24-1.fc13.src.rpm
elfutils-devel-static from elfutils-0.143-1.fc12.src.rpm
elfutils-libelf-devel-static from elfutils-0.143-1.fc12.src.rpm
libibverbs-devel-static from libibverbs-1.1.3-3.fc13.src.rpm
pciutils-devel-static from pciutils-3.1.4-6.fc13.src.rpm
Shared library -devel packages that provide a virtual -static package
and static libraries:
cdparanoia-devel from cdparanoia-10.2-6.fc13.src.rpm
/usr/lib/libcdda_interface.so <=> /usr/lib/libcdda_interface.a
/usr/lib/libcdda_paranoia.so <=> /usr/lib/libcdda_paranoia.a
e2fsprogs-devel from e2fsprogs-1.41.9-8.fc13.src.rpm
/usr/lib/libe2p.so <=> /usr/lib/libe2p.a
/usr/lib/libext2fs.so <=> /usr/lib/libext2fs.a
libblkid-devel from util-linux-ng-2.17-0.6.fc13.src.rpm
/usr/lib/libblkid.so <=> /usr/lib/libblkid.a
libcom_err-devel from e2fsprogs-1.41.9-8.fc13.src.rpm
/usr/lib/libcom_err.so <=> /usr/lib/libcom_err.a
libss-devel from e2fsprogs-1.41.9-8.fc13.src.rpm
/usr/lib/libss.so <=> /usr/lib/libss.a
libuuid-devel from util-linux-ng-2.17-0.6.fc13.src.rpm
/usr/lib/libuuid.so <=> /usr/lib/libuuid.a
mpich2-devel from mpich2-1.2.1-4.fc13.src.rpm
/usr/lib/mpich2/lib/libfmpich.so <=> /usr/lib/mpich2/lib/libfmpich.a
/usr/lib/mpich2/lib/libmpich.so <=> /usr/lib/mpich2/lib/libmpich.a
/usr/lib/mpich2/lib/libmpichcxx.so <=> /usr/lib/mpich2/lib/libmpichcxx.a
/usr/lib/mpich2/lib/libmpichf90.so <=> /usr/lib/mpich2/lib/libmpichf90.a
Shared library -devel packages that require a -static package:
Library-less -devel packages that require a -static package:
grib_api-devel from grib_api-1.7.0-4.fc12.src.rpm
libmimedir-devel from libmimedir-0.4-6.fc12.src.rpm
osiv-devel from osiv-2.0.0-0.8.beta.fc12.src.rpm
Mispackaged -static libraries:
Canna-devel from Canna-3.7p3-28.fc12.src.rpm
/usr/lib/libRKC.so <=> /usr/lib/libRKC.a
/usr/lib/libRKC16.so <=> /usr/lib/libRKC16.a
/usr/lib/libcanna.so <=> /usr/lib/libcanna.a
/usr/lib/libcanna16.so <=> /usr/lib/libcanna16.a
QuantLib-devel from QuantLib-0.9.7-6.fc12.src.rpm
/usr/lib/libQuantLib.so <=> /usr/lib/libQuantLib.a
atlas-3dnow-devel from atlas-3.8.3-12.fc13.src.rpm
/usr/lib/atlas-3dnow/libatlas.so <=> /usr/lib/atlas-3dnow/libatlas.a
/usr/lib/atlas-3dnow/libcblas.so <=> /usr/lib/atlas-3dnow/libcblas.a
/usr/lib/atlas-3dnow/libf77blas.so <=> /usr/lib/atlas-3dnow/libf77blas.a
/usr/lib/atlas-3dnow/liblapack.so <=> /usr/lib/atlas-3dnow/liblapack.a
/usr/lib/atlas-3dnow/libptcblas.so <=> /usr/lib/atlas-3dnow/libptcblas.a
/usr/lib/atlas-3dnow/libptf77blas.so <=> /usr/lib/atlas-3dnow/libptf77blas.a
atlas-devel from atlas-3.8.3-12.fc13.src.rpm
/usr/lib/atlas/libatlas.so <=> /usr/lib/atlas/libatlas.a
/usr/lib/atlas/libcblas.so <=> /usr/lib/atlas/libcblas.a
/usr/lib/atlas/libf77blas.so <=> /usr/lib/atlas/libf77blas.a
/usr/lib/atlas/liblapack.so <=> /usr/lib/atlas/liblapack.a
/usr/lib/atlas/libptcblas.so <=> /usr/lib/atlas/libptcblas.a
/usr/lib/atlas/libptf77blas.so <=> /usr/lib/atlas/libptf77blas.a
atlas-sse-devel from atlas-3.8.3-12.fc13.src.rpm
/usr/lib/atlas-sse/libatlas.so <=> /usr/lib/atlas-sse/libatlas.a
/usr/lib/atlas-sse/libcblas.so <=> /usr/lib/atlas-sse/libcblas.a
/usr/lib/atlas-sse/libf77blas.so <=> /usr/lib/atlas-sse/libf77blas.a
/usr/lib/atlas-sse/liblapack.so <=> /usr/lib/atlas-sse/liblapack.a
/usr/lib/atlas-sse/libptcblas.so <=> /usr/lib/atlas-sse/libptcblas.a
/usr/lib/atlas-sse/libptf77blas.so <=> /usr/lib/atlas-sse/libptf77blas.a
atlas-sse2-devel from atlas-3.8.3-12.fc13.src.rpm
/usr/lib/atlas-sse2/libatlas.so <=> /usr/lib/atlas-sse2/libatlas.a
/usr/lib/atlas-sse2/libcblas.so <=> /usr/lib/atlas-sse2/libcblas.a
/usr/lib/atlas-sse2/libf77blas.so <=> /usr/lib/atlas-sse2/libf77blas.a
/usr/lib/atlas-sse2/liblapack.so <=> /usr/lib/atlas-sse2/liblapack.a
/usr/lib/atlas-sse2/libptcblas.so <=> /usr/lib/atlas-sse2/libptcblas.a
/usr/lib/atlas-sse2/libptf77blas.so <=> /usr/lib/atlas-sse2/libptf77blas.a
atlas-sse3-devel from atlas-3.8.3-12.fc13.src.rpm
/usr/lib/atlas-sse3/libatlas.so <=> /usr/lib/atlas-sse3/libatlas.a
/usr/lib/atlas-sse3/libcblas.so <=> /usr/lib/atlas-sse3/libcblas.a
/usr/lib/atlas-sse3/libf77blas.so <=> /usr/lib/atlas-sse3/libf77blas.a
/usr/lib/atlas-sse3/liblapack.so <=> /usr/lib/atlas-sse3/liblapack.a
/usr/lib/atlas-sse3/libptcblas.so <=> /usr/lib/atlas-sse3/libptcblas.a
/usr/lib/atlas-sse3/libptf77blas.so <=> /usr/lib/atlas-sse3/libptf77blas.a
audit-libs-devel from audit-2.0.4-1.fc13.src.rpm
/usr/lib/libaudit.so <=> /usr/lib/libaudit.a
/usr/lib/libauparse.so <=> /usr/lib/libauparse.a
binutils-devel from binutils-2.20.51.0.2-11.fc13.src.rpm
/usr/lib/libbfd.so <=> /usr/lib/libbfd.a
/usr/lib/libopcodes.so <=> /usr/lib/libopcodes.a
brlapi-devel from brltty-4.1-3.fc13.src.rpm
/usr/lib/libbrlapi.so <=> /usr/lib/libbrlapi.a
cdparanoia-devel from cdparanoia-10.2-6.fc13.src.rpm
/usr/lib/libcdda_interface.so <=> /usr/lib/libcdda_interface.a
/usr/lib/libcdda_paranoia.so <=> /usr/lib/libcdda_paranoia.a
comedilib-devel from comedilib-0.8.1-5.fc12.src.rpm
/usr/lib/libcomedi.so <=> /usr/lib/libcomedi.a
dnssec-tools-libs-devel from dnssec-tools-1.5-5.fc13.src.rpm
/usr/lib/libsres.so <=> /usr/lib/libsres.a
/usr/lib/libval-threads.so <=> /usr/lib/libval-threads.a
/usr/lib/libval_shim.so <=> /usr/lib/libval_shim.a
e2fsprogs-devel from e2fsprogs-1.41.9-8.fc13.src.rpm
/usr/lib/libe2p.so <=> /usr/lib/libe2p.a
/usr/lib/libext2fs.so <=> /usr/lib/libext2fs.a
expat-devel from expat-2.0.1-8.fc13.src.rpm
/usr/lib/libexpat.so <=> /usr/lib/libexpat.a
fftw2-devel from fftw2-2.1.5-19.fc12.src.rpm
/usr/lib/libfftw.so <=> /usr/lib/libfftw.a
/usr/lib/libfftw_threads.so <=> /usr/lib/libfftw_threads.a
/usr/lib/librfftw.so <=> /usr/lib/librfftw.a
/usr/lib/librfftw_threads.so <=> /usr/lib/librfftw_threads.a
/usr/lib/libsfftw.so <=> /usr/lib/libsfftw.a
/usr/lib/libsfftw_threads.so <=> /usr/lib/libsfftw_threads.a
/usr/lib/libsrfftw.so <=> /usr/lib/libsrfftw.a
/usr/lib/libsrfftw_threads.so <=> /usr/lib/libsrfftw_threads.a
file-devel from file-5.03-17.fc13.src.rpm
/usr/lib/libmagic.so <=> /usr/lib/libmagic.a
gdbm-devel from gdbm-1.8.0-33.fc12.src.rpm
/usr/lib/libgdbm.so <=> /usr/lib/libgdbm.a
ghostscript-devel from ghostscript-8.70-3.fc13.src.rpm
/usr/lib/libijs.so <=> /usr/lib/libijs.a
gnutls-devel from gnutls-2.8.5-1.fc13.src.rpm
/usr/lib/libgnutls-extra.so <=> /usr/lib/libgnutls-extra.a
/usr/lib/libgnutls-openssl.so <=> /usr/lib/libgnutls-openssl.a
/usr/lib/libgnutls.so <=> /usr/lib/libgnutls.a
/usr/lib/libgnutlsxx.so <=> /usr/lib/libgnutlsxx.a
gpsim-devel from gpsim-0.24.0-1.fc12.src.rpm
/usr/lib/libgpsim.so <=> /usr/lib/libgpsim.a
/usr/lib/libgpsim_dspic.so <=> /usr/lib/libgpsim_dspic.a
/usr/lib/libgpsim_eXdbm.so <=> /usr/lib/libgpsim_eXdbm.a
/usr/lib/libgpsim_modules.so <=> /usr/lib/libgpsim_modules.a
/usr/lib/libgpsimcli.so <=> /usr/lib/libgpsimcli.a
/usr/lib/libgpsimgui.so <=> /usr/lib/libgpsimgui.a
gtk+extra-devel from gtk+extra-2.1.1-13.fc13.src.rpm
/usr/lib/libgtkextra-x11-2.0.so <=> /usr/lib/libgtkextra-x11-2.0.a
hesiod-devel from hesiod-3.1.0-16.src.rpm
/usr/lib/libhesiod.so <=> /usr/lib/libhesiod.a
hpic-devel from hpic-0.52.2-8.fc12.src.rpm
/usr/lib/libhpic.so <=> /usr/lib/libhpic.a
isdn4k-utils-devel from isdn4k-utils-3.2-67.fc13.src.rpm
/usr/lib/libcapi20.so <=> /usr/lib/libcapi20.a
js-devel from js-1.70-8.fc12.src.rpm
/usr/lib/libjs.so <=> /usr/lib/libjs.a
kpathsea-devel from texlive-2007-47.fc13.src.rpm
/usr/lib/libkpathsea.so <=> /usr/lib/libkpathsea.a
ldns-devel from ldns-1.6.3-1.fc13.src.rpm
/usr/lib/libldns.so <=> /usr/lib/libldns.a
libacl-devel from acl-2.2.49-2.fc13.src.rpm
/usr/lib/libacl.so <=> /usr/lib/libacl.a
libaio-devel from libaio-0.3.109-1.fc13.src.rpm
/usr/lib/libaio.so <=> /usr/lib/libaio.a
libannodex-devel from libannodex-0.7.3-12.fc12.src.rpm
/usr/lib/libannodex.so <=> /usr/lib/libannodex.a
libattr-devel from attr-2.4.44-1.fc13.src.rpm
/usr/lib/libattr.so <=> /usr/lib/libattr.a
libblkid-devel from util-linux-ng-2.17-0.6.fc13.src.rpm
/usr/lib/libblkid.so <=> /usr/lib/libblkid.a
libbtctl-devel from libbtctl-0.11.1-3.fc12.src.rpm
/usr/lib/libbtctl.so <=> /usr/lib/libbtctl.a
libcaca-devel from libcaca-0.99-0.9.beta16.fc12.src.rpm
/usr/lib/libcaca++.so <=> /usr/lib/libcaca++.a
/usr/lib/libcaca.so <=> /usr/lib/libcaca.a
libcddb-devel from libcddb-1.3.2-2.fc12.src.rpm
/usr/lib/libcddb.so <=> /usr/lib/libcddb.a
libcdio-devel from libcdio-0.81-3.fc12.src.rpm
/usr/lib/libcdio++.so <=> /usr/lib/libcdio++.a
/usr/lib/libcdio.so <=> /usr/lib/libcdio.a
/usr/lib/libcdio_cdda.so <=> /usr/lib/libcdio_cdda.a
/usr/lib/libcdio_paranoia.so <=> /usr/lib/libcdio_paranoia.a
/usr/lib/libiso9660++.so <=> /usr/lib/libiso9660++.a
/usr/lib/libiso9660.so <=> /usr/lib/libiso9660.a
/usr/lib/libudf.so <=> /usr/lib/libudf.a
libcmml-devel from libcmml-0.9.1-7.fc12.src.rpm
/usr/lib/libcmml.so <=> /usr/lib/libcmml.a
libcom_err-devel from e2fsprogs-1.41.9-8.fc13.src.rpm
/usr/lib/libcom_err.so <=> /usr/lib/libcom_err.a
libdnet-devel from libdnet-1.12-5.fc12.src.rpm
/usr/lib/libdnet.so <=> /usr/lib/libdnet.a
libevent-devel from libevent-1.4.13-1.fc13.src.rpm
/usr/lib/libevent.so <=> /usr/lib/libevent.a
/usr/lib/libevent_core.so <=> /usr/lib/libevent_core.a
/usr/lib/libevent_extra.so <=> /usr/lib/libevent_extra.a
libftdi-c++-devel from libftdi-0.17-1.fc13.src.rpm
/usr/lib/libftdipp.so <=> /usr/lib/libftdipp.a
libftdi-devel from libftdi-0.17-1.fc13.src.rpm
/usr/lib/libftdi.so <=> /usr/lib/libftdi.a
libgnat-devel from gcc-4.4.2-20.fc13.src.rpm
/usr/lib/gcc/i686-redhat-linux/4.4.2/adalib/libgnarl.so <=> /usr/lib/gcc/i686-redhat-linux/4.4.2/adalib/libgnarl.a
/usr/lib/gcc/i686-redhat-linux/4.4.2/adalib/libgnat.so <=> /usr/lib/gcc/i686-redhat-linux/4.4.2/adalib/libgnat.a
libmudflap-devel from gcc-4.4.2-20.fc13.src.rpm
/usr/lib/gcc/i686-redhat-linux/4.4.2/libmudflap.so <=> /usr/lib/gcc/i686-redhat-linux/4.4.2/libmudflap.a
/usr/lib/gcc/i686-redhat-linux/4.4.2/libmudflapth.so <=> /usr/lib/gcc/i686-redhat-linux/4.4.2/libmudflapth.a
libnl-devel from libnl-1.1-8.fc12.src.rpm
/usr/lib/libnl.so <=> /usr/lib/libnl.a
liboggz-devel from liboggz-0.9.8-4.fc12.src.rpm
/usr/lib/liboggz.so <=> /usr/lib/liboggz.a
libotr-devel from libotr-3.2.0-4.fc12.src.rpm
/usr/lib/libotr.so <=> /usr/lib/libotr.a
librx-devel from librx-1.5-14.fc12.src.rpm
/usr/lib/librx.so <=> /usr/lib/librx.a
libsemanage-devel from libsemanage-2.0.43-2.fc13.src.rpm
/usr/lib/libsemanage.so <=> /usr/lib/libsemanage.a
libsndfile-devel from libsndfile-1.0.20-4.fc13.src.rpm
/usr/lib/libsndfile.so <=> /usr/lib/libsndfile.a
libss-devel from e2fsprogs-1.41.9-8.fc13.src.rpm
/usr/lib/libss.so <=> /usr/lib/libss.a
libstatgrab-devel from libstatgrab-0.16-3.fc12.src.rpm
/usr/lib/libstatgrab.so <=> /usr/lib/libstatgrab.a
libstdc++-devel from gcc-4.4.2-20.fc13.src.rpm
/usr/lib/gcc/i686-redhat-linux/4.4.2/libstdc++.so <=> /usr/lib/gcc/i686-redhat-linux/4.4.2/libstdc++.a
libsysfs-devel from sysfsutils-2.1.0-6.fc12.src.rpm
/usr/lib/libsysfs.so <=> /usr/lib/libsysfs.a
libtorque-devel from torque-2.1.10-8.fc12.src.rpm
/usr/lib/libtorque.so <=> /usr/lib/libtorque.a
libtranslate-devel from libtranslate-0.99-22.fc12.src.rpm
/usr/lib/libtranslate.so <=> /usr/lib/libtranslate.a
libtwin-devel from libtwin-0.0.3-3.fc12.src.rpm
/usr/lib/libtwin.so <=> /usr/lib/libtwin.a
libuninameslist-devel from libuninameslist-20080409-3.fc12.src.rpm
/usr/lib/libuninameslist-fr.so <=> /usr/lib/libuninameslist-fr.a
/usr/lib/libuninameslist.so <=> /usr/lib/libuninameslist.a
libuuid-devel from util-linux-ng-2.17-0.6.fc13.src.rpm
/usr/lib/libuuid.so <=> /usr/lib/libuuid.a
libxslt-devel from libxslt-1.1.26-1.fc12.src.rpm
/usr/lib/libexslt.so <=> /usr/lib/libexslt.a
/usr/lib/libxslt.so <=> /usr/lib/libxslt.a
link-grammar-devel from link-grammar-4.3.5-5.fc12.src.rpm
/usr/lib/liblink-grammar.so <=> /usr/lib/liblink-grammar.a
linux-atm-libs-devel from linux-atm-2.5.0-10.src.rpm
/usr/lib/libatm.so <=> /usr/lib/libatm.a
linuxwacom-devel from linuxwacom-0.8.2.2-17.fc12.src.rpm
/usr/lib/libwacomcfg.so <=> /usr/lib/libwacomcfg.a
lockdev-devel from lockdev-1.0.3-3.fc13.src.rpm
/usr/lib/liblockdev.so <=> /usr/lib/liblockdev.a
meanwhile-devel from meanwhile-1.1.0-2.fc12.src.rpm
/usr/lib/libmeanwhile.so <=> /usr/lib/libmeanwhile.a
mpich2-devel from mpich2-1.2.1-4.fc13.src.rpm
/usr/lib/mpich2/lib/libfmpich.so <=> /usr/lib/mpich2/lib/libfmpich.a
/usr/lib/mpich2/lib/libmpich.so <=> /usr/lib/mpich2/lib/libmpich.a
/usr/lib/mpich2/lib/libmpichcxx.so <=> /usr/lib/mpich2/lib/libmpichcxx.a
/usr/lib/mpich2/lib/libmpichf90.so <=> /usr/lib/mpich2/lib/libmpichf90.a
munipack-devel from munipack-1.1.24-3.fc12.src.rpm
/usr/lib/libcmunipack.so <=> /usr/lib/libcmunipack.a
mysql-devel from mysql-5.1.42-2.fc13.src.rpm
/usr/lib/mysql/libmysqlclient.so <=> /usr/lib/mysql/libmysqlclient.a
/usr/lib/mysql/libmysqlclient_r.so <=> /usr/lib/mysql/libmysqlclient_r.a
/usr/lib/mysql/libndbclient.so <=> /usr/lib/mysql/libndbclient.a
nfs-utils-lib-devel from nfs-utils-lib-1.1.4-8.fc12.src.rpm
/usr/lib/libnfsidmap.so <=> /usr/lib/libnfsidmap.a
/usr/lib/libnfsidmap.so <=> /usr/lib/libnfsidmap_static.a
/usr/lib/libnfsidmap_nsswitch.so <=> /usr/lib/libnfsidmap_nsswitch.a
/usr/lib/libnfsidmap_static.so <=> /usr/lib/libnfsidmap_static.a
/usr/lib/libnfsidmap_umich_ldap.so <=> /usr/lib/libnfsidmap_umich_ldap.a
/usr/lib/librpcsecgss.so <=> /usr/lib/librpcsecgss.a
numactl-devel from numactl-2.0.3-7.fc12.src.rpm
/usr/lib/libnuma.so <=> /usr/lib/libnuma.a
opencdk-devel from opencdk-0.6.6-4.fc12.src.rpm
/usr/lib/libopencdk.so <=> /usr/lib/libopencdk.a
openldap-devel from openldap-2.4.19-3.fc13.src.rpm
/usr/lib/liblber.so <=> /usr/lib/liblber.a
/usr/lib/libldap.so <=> /usr/lib/libldap.a
/usr/lib/libldap_r.so <=> /usr/lib/libldap_r.a
postgresql-devel from postgresql-8.4.2-1.fc13.src.rpm
/usr/lib/libecpg.so <=> /usr/lib/libecpg.a
/usr/lib/libecpg_compat.so <=> /usr/lib/libecpg_compat.a
/usr/lib/libpgtypes.so <=> /usr/lib/libpgtypes.a
/usr/lib/libpq.so <=> /usr/lib/libpq.a
proj-devel from proj-4.7.0-1.fc13.src.rpm
/usr/lib/libproj.so <=> /usr/lib/libproj.a
python-devel from python-2.6.4-4.fc13.src.rpm
/usr/lib/python2.6/config/libpython2.6.so <=> /usr/lib/python2.6/config/libpython2.6.a
rubberband-devel from rubberband-1.2-5.fc12.src.rpm
/usr/lib/librubberband.so <=> /usr/lib/librubberband.a
shapelib-devel from shapelib-1.2.10-20.20060304cvs.src.rpm
/usr/lib/libshp.so <=> /usr/lib/libshp.a
syck-devel from syck-0.61-9.3.fc12.src.rpm
/usr/lib/libsyck.so <=> /usr/lib/libsyck.a
util-vserver-devel from util-vserver-0.30.215+svn2847-143596525.fc12.src.rpm
/usr/lib/libvserver.so <=> /usr/lib/libvserver.a
xbsql-devel from xbsql-0.11-14.fc12.src.rpm
/usr/lib/libxbsql.so <=> /usr/lib/libxbsql.a
xen-devel from xen-3.4.2-2.fc13.src.rpm
/usr/lib/libblktap.so <=> /usr/lib/libblktap.a
/usr/lib/libflask.so <=> /usr/lib/libflask.a
/usr/lib/libxenctrl.so <=> /usr/lib/libxenctrl.a
/usr/lib/libxenguest.so <=> /usr/lib/libxenguest.a
/usr/lib/libxenstore.so <=> /usr/lib/libxenstore.a
xfsprogs-devel from xfsprogs-3.0.3-5.fc13.src.rpm
/usr/lib/libhandle.so <=> /usr/lib/libhandle.a
xmlsec1-devel from xmlsec1-1.2.12-2.fc12.src.rpm
/usr/lib/libxmlsec1.so <=> /usr/lib/libxmlsec1.a
xmlsec1-gnutls-devel from xmlsec1-1.2.12-2.fc12.src.rpm
/usr/lib/libxmlsec1-gnutls.so <=> /usr/lib/libxmlsec1-gnutls.a
xmlsec1-nss-devel from xmlsec1-1.2.12-2.fc12.src.rpm
/usr/lib/libxmlsec1-nss.so <=> /usr/lib/libxmlsec1-nss.a
xmlsec1-openssl-devel from xmlsec1-1.2.12-2.fc12.src.rpm
/usr/lib/libxmlsec1-openssl.so <=> /usr/lib/libxmlsec1-openssl.a
From tgl at redhat.com Tue Jan 5 16:03:24 2010
From: tgl at redhat.com (Tom Lane)
Date: Tue, 05 Jan 2010 11:03:24 -0500
Subject: [Fedora-packaging] Our static Libraries packaging guidelines
once more
In-Reply-To: <20100105160821.59fbef0b@gmail.com>
References: <20091205181941.600ac00f@gmail.com> <20091205180049.GF4179@free.fr>
<20091205191847.2c9c6aa1@gmail.com> <4B1CFFEE.7020306@jcomserv.net>
<20091207193525.71338163@gmail.com>
<20100105160821.59fbef0b@gmail.com>
Message-ID: <10344.1262707404@sss.pgh.pa.us>
Michael Schwendt writes:
> How much do we adhere to our Packaging Guidelines for static libraries?
> https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries
> Mispackaged -static libraries:
> mysql-devel from mysql-5.1.42-2.fc13.src.rpm
> postgresql-devel from postgresql-8.4.2-1.fc13.src.rpm
As far as these two go, I think it's just a matter of the specfiles
dating from years before we had any such guideline, and not revisiting
the point since then. I don't have any particular objection to removing
the static versions of their libraries. On the other hand, with the
guideline being so widely ignored, I'm not in a hurry to do work to
comply with it ...
regards, tom lane
From richmattes at gmail.com Wed Jan 6 03:24:22 2010
From: richmattes at gmail.com (Rich Mattes)
Date: Tue, 05 Jan 2010 22:24:22 -0500
Subject: [Fedora-packaging] Request for Guideline Clarification
In-Reply-To: <8716aadc06772f10732c1112146a5a6f.squirrel@secure.jcomserv.net>
References: <4B2EB344.7050505@gmail.com>
<8716aadc06772f10732c1112146a5a6f.squirrel@secure.jcomserv.net>
Message-ID: <4B440266.9000508@gmail.com>
I went ahead and created a set of draft guidelines for discussion,
located at https://fedoraproject.org/wiki/PackagingDrafts/SharedLibraries
I tried to go by common practices, what the FHS states, etc. Let me
know if I've missed the mark on anything or left something out.
Rich
On 12/21/2009 04:31 PM, Jon Ciesla wrote:
>
> > Hi all,
> >
> > I've been gathering bits and pieces of information regarding the
> > packaging of shared libraries for a while now. As I understand it:
> >
> > - Normal .so libraries with versioned filenames go into the base package
> > for a program when they exist
>
> Yes.
>
> > - Unversioned .so libraries go into the -devel package
>
> Yes.
>
> > -- If there are no versioned libraries for a program, should a
> > versioned library be added or should the unversioned .so file be
> > included in the base package?
>
> Option B, I think, but someone else with more insight should chime in. . .
>
> > - Libraries which are used by other programs at runtime should be
> > versioned, and in %{_libdir}
> > -- Are there exceptions to this? When is it appropriate to leverage
> > subdirectories and /etc/ld.so.conf.d/?
>
> How so, by adding a path to /etc/ld.so.conf?
>
> > - Libraries which are plugins to one specific program, and are dlopened
> > by that program, do not need a versioned filename. They should go in
> > their own subdierctory in %{_libdir} (e.g. /usr/lib/gstreamer-0.10)
> > -- If packaged as seperate plugins, they should be in packages called
> > packagename-plugins-pluginname, or something similar
> >
> > - All shared library filenames should begin with lib
>
>
>
> > A lot of this isn't in the packaging guidelines, I think if these points
> > could be clarified and included in the guidelines it would help to
> > answer a lot of questions.
>
> If you like, you can write up a draft, and post here, or submit to the
> FPC.
>
> https://fedoraproject.org/wiki/Packaging:Committee
>
> > Thanks,
> >
> > Rich
> >
> > --
> > Fedora-packaging mailing list
> > Fedora-packaging at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-packaging
> >
>
>
> --
> in your fear, seek only peace
> in your fear, seek only love
>
> -d. bowie
>
>
> --
> Fedora-packaging mailing list
> Fedora-packaging at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
>
From a.badger at gmail.com Wed Jan 6 03:49:33 2010
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 5 Jan 2010 22:49:33 -0500
Subject: [Fedora-packaging] Suggested specification to changelog
guidelines
In-Reply-To: <19532.1262469978@sss.pgh.pa.us>
References: <1262467999.21612.1.camel@localhost>
<19532.1262469978@sss.pgh.pa.us>
Message-ID: <20100106034933.GB2822@clingman.lan>
On Sat, Jan 02, 2010 at 05:06:18PM -0500, Tom Lane wrote:
> Jussi Lehtola writes:
> > I'd like to suggest
> > https://fedoraproject.org/wiki/PackagingDrafts/ChangelogStyles
> > for discussion.
>
> Not a good idea. Different people do this differently, and
> since some of those people are doing bulk rebuilds, there's no
> way to guarantee that exactly the same format will be followed
> in all the historical entries in a changelog. Or do you envision
> that people will actually retroactively change old log entries
> to match their preferred format? Now *that* would be a bad idea.
>
I pretty much agree with Tom's arguments here. Jussi, if you want to put
this up for a vote you can but I don't think it would pass without showing:
1) what the benefits are
2) how to address Tom's concerns about old log entries, multiple
maintainers, etc.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
From jussilehtola at fedoraproject.org Wed Jan 6 10:08:00 2010
From: jussilehtola at fedoraproject.org (Jussi Lehtola)
Date: Wed, 06 Jan 2010 12:08:00 +0200
Subject: [Fedora-packaging] Suggested specification to changelog
guidelines
In-Reply-To: <20100106034933.GB2822@clingman.lan>
References: <1262467999.21612.1.camel@localhost>
<19532.1262469978@sss.pgh.pa.us> <20100106034933.GB2822@clingman.lan>
Message-ID: <1262772480.6487.0.camel@localhost>
On Tue, 2010-01-05 at 22:49 -0500, Toshio Kuratomi wrote:
> On Sat, Jan 02, 2010 at 05:06:18PM -0500, Tom Lane wrote:
> > Jussi Lehtola writes:
> > > I'd like to suggest
> > > https://fedoraproject.org/wiki/PackagingDrafts/ChangelogStyles
> > > for discussion.
> >
> > Not a good idea. Different people do this differently, and
> > since some of those people are doing bulk rebuilds, there's no
> > way to guarantee that exactly the same format will be followed
> > in all the historical entries in a changelog. Or do you envision
> > that people will actually retroactively change old log entries
> > to match their preferred format? Now *that* would be a bad idea.
> >
> I pretty much agree with Tom's arguments here. Jussi, if you want to put
> this up for a vote you can but I don't think it would pass without showing:
>
> 1) what the benefits are
>
> 2) how to address Tom's concerns about old log entries, multiple
> maintainers, etc.
Yes, I'm pulling this one out.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola at fedoraproject.org
From mschwendt at gmail.com Wed Jan 6 10:18:19 2010
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 6 Jan 2010 11:18:19 +0100
Subject: [Fedora-packaging] Request for Guideline Clarification
In-Reply-To: <4B440266.9000508@gmail.com>
References: <4B2EB344.7050505@gmail.com>
<8716aadc06772f10732c1112146a5a6f.squirrel@secure.jcomserv.net>
<4B440266.9000508@gmail.com>
Message-ID: <20100106111819.2a7c08e1@gmail.com>
On Tue, 05 Jan 2010 22:24:22 -0500, Rich wrote:
> I went ahead and created a set of draft guidelines for discussion,
> located at https://fedoraproject.org/wiki/PackagingDrafts/SharedLibraries
>
> I tried to go by common practices, what the FHS states, etc. Let me
> know if I've missed the mark on anything or left something out.
Much too vague/ambiguous, especially for newbie packagers, who feel
clobbered by the current guidelines already. It is increasingly difficult
to create guidelines that simply say "do this" or "don't do that" without
giving a clear but long rationale that covers corner-cases even.
| If a library is providing resources that other packages may need at
| compile or runtime,
The difference between compile- and runtime is important enough not
to cover both in the same sentence. Also, what "resources" do you
refer to here?
| it should be installed directly to the default
| library search path.
Why? And why "the default"?
| Wherever possible, these libraries should be created with versioning in
| the filename,
Vague.
| and provide a set of unversioned symlinks in a -devel file.
This adds confusion. It is perfectly valid for a library to be called
libfoo-0.10.so.0 with a libfoo-0.10.so symlink.
| In the case that a package only contains unversioned libraries, they
| may be included in the non-devel base packages.
Insufficient for a general guideline. See further below in this mail, too.
| If libraries are installed into a subdirectory and do need to be on the
| system library search path, an entry in /etc/ld.so.conf.d/ may be created
| to add a subdirectory to the ld search path
If at all, there could be a future section on documenting ld.so.conf usage
a bit more. Adding library search paths that way effectively makes the
libs available to the run-time linker prior to searching in the trusted
default paths.
| Libraries in %{_libdir} subdirectores do not need versioning in their
| filenames.
But of course they do, if you add them via ld.so.conf.d entries.
"ldconfig -vp|less" The filename is not so important. A library's SONAME is.
> > > I've been gathering bits and pieces of information regarding the
> > > packaging of shared libraries for a while now. As I understand it:
> > >
> > > - Normal .so libraries with versioned filenames go into the base package
> > > for a program when they exist
> >
> > Yes.
> >
> > > - Unversioned .so libraries go into the -devel package
> >
> > Yes.
It cannot be answered with a plain "Yes", because such .so files may
be plugins/modules loaded at run-time. Several package submitters
have mispackaged such files because somebody told them that .so would
need to go into -devel packages.
> > > -- If there are no versioned libraries for a program, should a
> > > versioned library be added or should the unversioned .so file be
> > > included in the base package?
> >
> > Option B, I think, but someone else with more insight should chime in. . .
The question is too vague. Does it refer to system libraries? And
does "version" refer to a number in the library SONAME?
Typically, you cannot make up your own versioned library SONAME without
creating incompatibilities. As long as the program authors don't use the
same SONAME together with a sane library versioning scheme, you would
run your own show.
There are approaches that increase the package maintenance requirements
and add incompatibilities, such as building from a libfoo.so (or libfoo.a)
a libfoo-VERSION.so.0, which would require a modification of any app that
linked with plain -lfoo and now would need to link with -lfoo-VERSION.
Contact upstream. Though, it may be that they even refuse to apply
a patch for building a proper shared library, because they want to
continue with changing the API even in minor releases.
> > > - Libraries which are used by other programs at runtime should be
> > > versioned, and in %{_libdir}
> > > -- Are there exceptions to this? When is it appropriate to leverage
> > > subdirectories and /etc/ld.so.conf.d/?
Note that it may be that the upstream distribution does that by default.
It's convenient for any library stack you would want to swap out at run-time
(and with avoidance of file conflicts at install-time).
Think "alternatives" for libraries. Multiple builds of a library with the
same name but different build options or different releases.
> > > - Libraries which are plugins to one specific program, and are dlopened
> > > by that program, do not need a versioned filename. They should go in
> > > their own subdierctory in %{_libdir} (e.g. /usr/lib/gstreamer-0.10)
> > > -- If packaged as seperate plugins, they should be in packages called
> > > packagename-plugins-pluginname, or something similar
> > >
> > > - All shared library filenames should begin with lib
Why?
For example, plugins/modules as well as LT_PRELOADed shared libraries
don't need to begin with "lib".
From orion at cora.nwra.com Wed Jan 6 20:56:22 2010
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 06 Jan 2010 13:56:22 -0700
Subject: [Fedora-packaging] Naming packages from apache.org
Message-ID: <4B44F8F6.7030007@cora.nwra.com>
crossposting to java and packaging -
Seems like we need an accepted standard for naming packages from
apache.org, particularly commons.apache.org. We already have lots of
"jakarta-commons-*" packages, but now "commons" is an ex-jakarta project
and jakarta.apache.org/commons redirects to commons.apache.org. Same
with jakarta taglibs (although that moved to tomcat).
As of now, the only apache-* package I know of is apache-ivy, which I
would have named simply "ivy". I've got a package request in for
"commons-jexl"[1], but it has been suggested that it be named
apache-commons-jexl. If it were named that I would want a Provides:
commons-jexl much like most jakarta-commons-* packages, so it doesn't
really clean up the namespace any (just adds to it in fact).
commons-* is a lousy name though too, be very generic.
So, I'm fine with either (although I think it's quite possible that
"apache commons" could get renamed again), but at this juncture before a
bunch more packages come in from apache commons, I think we should make
a decision and stick with it.
1 - https://bugzilla.redhat.com/show_bug.cgi?id=531379
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion at cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
From akurtako at redhat.com Thu Jan 7 09:54:36 2010
From: akurtako at redhat.com (Alexander Kurtakov)
Date: Thu, 7 Jan 2010 11:54:36 +0200
Subject: [Fedora-packaging] Naming packages from apache.org
In-Reply-To: <4B44F8F6.7030007@cora.nwra.com>
References: <4B44F8F6.7030007@cora.nwra.com>
Message-ID: <201001071154.39090.akurtako@redhat.com>
As I have stated it in the bug report we should go with apache-commons.
Alex
> crossposting to java and packaging -
>
> Seems like we need an accepted standard for naming packages from
> apache.org, particularly commons.apache.org. We already have lots of
> "jakarta-commons-*" packages, but now "commons" is an ex-jakarta project
> and jakarta.apache.org/commons redirects to commons.apache.org. Same
> with jakarta taglibs (although that moved to tomcat).
>
> As of now, the only apache-* package I know of is apache-ivy, which I
> would have named simply "ivy". I've got a package request in for
> "commons-jexl"[1], but it has been suggested that it be named
> apache-commons-jexl. If it were named that I would want a Provides:
> commons-jexl much like most jakarta-commons-* packages, so it doesn't
> really clean up the namespace any (just adds to it in fact).
>
> commons-* is a lousy name though too, be very generic.
>
> So, I'm fine with either (although I think it's quite possible that
> "apache commons" could get renamed again), but at this juncture before a
> bunch more packages come in from apache commons, I think we should make
> a decision and stick with it.
>
> 1 - https://bugzilla.redhat.com/show_bug.cgi?id=531379
>
From overholt at redhat.com Thu Jan 7 19:32:10 2010
From: overholt at redhat.com (Andrew Overholt)
Date: Thu, 7 Jan 2010 14:32:10 -0500
Subject: [Fedora-packaging] [fedora-java] Naming packages from apache.org
In-Reply-To: <4B44F8F6.7030007@cora.nwra.com>
References: <4B44F8F6.7030007@cora.nwra.com>
Message-ID: <20100107193210.GA1709@redhat.com>
* Orion Poplawski [2010-01-06 16:02]:
> before a bunch more packages come in from apache commons, I think we
> should make a decision and stick with it.
I vote for apache-commons-*. I also think a re-name with suitable
Provides/Obsoletes is in order.
Andrew
From overholt at redhat.com Thu Jan 7 19:42:33 2010
From: overholt at redhat.com (Andrew Overholt)
Date: Thu, 7 Jan 2010 14:42:33 -0500
Subject: [Fedora-packaging] Suggested updated Java guidelines
In-Reply-To: <1262443624.6749.1609.camel@localhost>
References: <1262443624.6749.1609.camel@localhost>
Message-ID: <20100107194232.GB1709@redhat.com>
Hi,
* Alexander Bostr?m [2010-01-02 09:54]:
> I submitted a review for java-gnome and working on that made me think
> the Java guidelines needs work, so here's a suggested update:
Thanks for doing this!
> Removed some occurances of a Unicode control character that didn't seem
> to belong there.
Cool.
> Fixed formatting of the text under "Jar file naming".
Okay.
> Hopefully clarified the text under "Directory structure".
This is fine. The "JNI" link is still broken but that's not new :)
> Changed some occuranced of "%{_xxx}" into
> "%{_xxx}".
>
> Changed -javadoc Group tag from "Development Documentation" to
> "Documentation".
Thanks.
> Mostly rewrote the section on JNI packaging. (See wiki.)
This looks good.
> Removed this text:
>
> The %{_jnidir} rpm macro defines the main JNI jar
> repository. Like %{_javadir} it is declined in
> -ext and -x.y.z variants. It follows
> exactly the same rules as the %{_javadir}-derived
> tree structure, except that it hosts JAR files that use JNI.
>
> %{_jnidir} usually expands into
> /usr/lib/java.
>
> It seems to belong to the "The plan is to eventually..." part, but I
> don't really understand it. Explain and I'll add something back. :)
First off, "declined" should be "defined". I think the "-ext" and
"-x.y.z" variants are JVM package variabnts. It's unfortunate that we
can't have a standard directory structure defined in jpackage-utils.
I'm not sure the macro is useful enough to warrant this
potentially-confusing text.
> Partially rewrote the section on prebuilt binaries and the suggested %
> prep section. (See wiki.)
This is good, thanks.
I think all of these changes will benefit the guidelines and would like
to see them added to the wiki.
Andrew
From nicolas.mailhot at laposte.net Thu Jan 7 20:23:02 2010
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 07 Jan 2010 21:23:02 +0100
Subject: [Fedora-packaging] Suggested updated Java guidelines
In-Reply-To: <1262443624.6749.1609.camel@localhost>
References: <1262443624.6749.1609.camel@localhost>
Message-ID: <1262895782.3818.33.camel@arekh.okg>
Le samedi 02 janvier 2010 ? 15:47 +0100, Alexander Bostr?m a ?crit :
> Removed this text:
>
> The %{_jnidir} rpm macro defines the main JNI jar
> repository. Like %{_javadir} it is declined in
> -ext and -x.y.z variants. It follows
> exactly the same rules as the %{_javadir}-derived
> tree structure, except that it hosts JAR files that use JNI.
>
> %{_jnidir} usually expands into
> /usr/lib/java.
>
> It seems to belong to the "The plan is to eventually..." part, but I
> don't really understand it. Explain and I'll add something back. :)
When the original JJP guidelines were written people were using lots of
different JVMs and app writers were releasing code that only worked on
specific java versions, so the original JPP directory structure has
always allowed versionned directories where packagers could put jars
that only worked on specific versions.
If you look at the shell code macro that resolves filenames in
jpackages-utils, you'll see it does something like the following when
looking for jar "foo"
1. check the java version the current jvm reports (for example x.y.z)
2. look for "foo.jar" in %{_jnidir}-x.y.z/
3. look for "foo.jar" in %{_jnidir}-x.y/
4. look for "foo.jar" in %{_jnidir}-x/
5. look for "foo.jar" in %{_jnidir}/
6. look for "foo.jar" in %{_javadir}-x.y.z/
7. look for "foo.jar" in %{_javadir}-x.y/
8. look for "foo.jar" in %{_javadir}-x/
9. look for "foo.jar" in %{_javadir}/
That allowed nifty things like having a single tomcat package (+ deps)
that worked both with java-1.3 and java-1.4 jvms, depending on the jvm
installed on system (or even with multiple jvms installed and env var
changes), at a time when users where split between boths, and creating
separate 1.3 and 1.4 packaging stacks would not have been possible for
lack of manpower (90% of the components where the same with 1.3 and 1.4,
the few exceptions were a PITA to manage)
People tend to put all their jars in %{_javadir}/ nowadays, but the
infra is still there to allow multiple versions if needed.
BTW: this part of jpackage-utils was written in a week-end and was
intended as a short-term simple brutal implementation while better
people created better mechanisms. Better didn't happen years later :(
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
From nicolas.mailhot at laposte.net Fri Jan 8 12:52:29 2010
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 8 Jan 2010 13:52:29 +0100
Subject: [Fedora-packaging] Suggested specification to changelog
guidelines
In-Reply-To: <1262467999.21612.1.camel@localhost>
References: <1262467999.21612.1.camel@localhost>
Message-ID: <1cf2d890259220f79dfb89344c2798fc.squirrel@arekh.dyndns.org>
Le Sam 2 janvier 2010 22:33, Jussi Lehtola a ?crit :
> I'd like to suggest
> https://fedoraproject.org/wiki/PackagingDrafts/ChangelogStyles
>
> for discussion. Now some packages mix the styles, which IMHO is bad
> style.
I don't think it is possible to forbid style mixing as releng scripts add new
entries during operations such as mass rebuilds without checking what the
current style is.
--
Nicolas Mailhot