packaging May 2009

packaging@lists.fedoraproject.org

49 participants
29 discussions

Re: [Fedora-packaging] Java guideline inconsistency
by Fernando Nasser 09 May '09

09 May '09

I think this is a bit pertinent to the discussion so I thought I should mention it. A few Java developer communities have contacted jpackage.org in the past (some contacted myself personally) asking for the organization name to be used as a prefix. One of these was ObjectWeb. Have you noticed that asm became objectwb-asm? We have a conflict (I believe not on Fedora) with a package called hibernate. The conflict is not happening by chance, as the Java hibenate package was made hibernate3 when the release 3 appeared and the 2 was stil around. Conveniently, I have been recently questioned by some JBoss person why the package was not called jboss-hibernate. Maybe we should oblige :-) There are lots of Java packages that already follow this practice in most Linux distros and we ourselves have the jakarta-* and apache-* and geronimo-* and so on. So we are basically covered on the "N" side of things. The JAR file names are not a problem as they go under %{_javadir} and won't conflict with non-Jva packages (no more .so's with OpenJDK), The only remaining conflicts are for commands (wrapper scripts mostly for Java) that are installed in /usr/bin. Not all Java packages have scripts there though. In theory some SysV init scripts or /etc/sysconfig/ stuff could collide too, but in all these years we had no such case and we can always bury it under a subdirectory with the package name, so in practice only /usr/bin commands can conflict. One of the conflicting commands will have to be renamed if this ever happens. Note that this is not exclusive of Java, any two softwares written in any two languages can decide to call a command "twitter" for instance. Regards, Fernando ----- Original Message ----- From: "Toshio Kuratomi" <a.badger(a)gmail.com> To: "Discussion of RPM packaging standards and practices for Fedora" <fedora-packaging(a)redhat.com> Sent: Saturday, May 9, 2009 1:11:15 PM GMT -05:00 US/Canada Eastern Subject: Re: [Fedora-packaging] Java guideline inconsistency Peter Lemenkov wrote: > 2009/5/9 Jussi Lehtola <jussi.lehtola(a)iki.fi>: > >> Quite on the contrary. I think prefixes are quite useful, since many >> language specific packages might have otherwise conflicting names > > Not a names, but a *filenames*. This should be fixed as well - I don't > think that there is a reason to maintain correspondence between %name > field and the resulting rpm's filenames (or even to maintain > human-readable rpm filenames), at least in main repositories. > There isn't a correspondence. Or rather, the correspondence you see is entirely cosmetic. the rpm _filenames_ are entirely for the convenience of the humans who have to deal with them. The rpm Name attribute is what rpm, yum, and the package manager depend on. And conflicts between the rpm Name attribute are very bad. If we had two different packages with Name: argparse and one was a library for java and one was for python we could rename the filenames so that they can both exist in the repositories. But the moment you go to install them you have a conflicting rpm name and have problems: * Which of the two packages will be installed when you run yum install argparse? * How do you install both packages at the same time? * How do you prevent one package from upgrading the other package since the name is the same in the rpm database? and so on and so forth. -Toshio -- Fedora-packaging mailing list Fedora-packaging(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging

2 1

Re: [Fedora-packaging] Java guideline inconsistency
by Fernando Nasser 09 May '09

09 May '09

Hi guys, I wouldn't waste much time on this. The new "de facto" standard for installation is the one defined by Maven anyway. Even Java software that does not build with Maven grabs data from maven repositories these days (with Ant <get>, or something else). JPP 6, RHEL-based products and future Fedora Java package updates will all install the JARs following strictly the Maven standard layout with unversioned symlinks. One of the advantages of this is that it does not require any maven patch (although I'd like to keep the depmap) and facilitates regular (non-RPM) maven builds by developers. Another is that a maven repo installed with RPMs can be made available as a multi-platform remote Maven repository. Last but not least, it greatly facilitates parallel installation of diferent versions. Although that is not recommended, we have some unavoidable cases so better account for them. We will need to keep some of the old JAR file names as deprecated for a release or so for backwads compatibility or while the conversion takes place, but these are exactly like Jussi wants, unversioned. Some preliminary tests were already made with good results. Once we have ironed out some last details (I'd like a simpler mvn command line invocation for one thing and some scripts in jpackage-utils have to be enhanced or added) I can post a basic description of how each package should install its JARs for this to work. I need to find a good link describing the default maven repository layout as reference to keep it simple and authoritative. Regards to all, Fernando ----- Original Message ----- From: "Andrew Overholt" <overholt(a)redhat.com> To: "Discussion of RPM packaging standards and practices for Fedora" <fedora-packaging(a)redhat.com> Sent: Saturday, May 9, 2009 4:44:11 PM GMT -05:00 US/Canada Eastern Subject: Re: [Fedora-packaging] Java guideline inconsistency * Toshio Kuratomi <a.badger(a)gmail.com> [2009-05-09 13:25]: > Jussi Lehtola wrote: > > > > there seems to be an inconsistency with the Java guidelines: > > http://fedoraproject.org/wiki/Packaging/Java > > > > http://fedoraproject.org/wiki/Packaging/Java#Jar_file_naming states that > > if the package only contains a single .jar file it should have the same > > name as the package, but the ant and maven spec file templates > > install .jar files as > > > > cp -p [build path to jar] \ > > $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar > > > I would lean towards Java#Jar_file_naming being clarified but I'm not a > java guy. Andrew, Fernando, Deepak, someone want to write up a > clarification of this? Sure, I'll speak about this with Deepak and others and get something written up. > > Also, I find it a bit inconsistent that java packages don't have to have > > a java- prefix as python, perl, php and so on packages have to. > > I do to but I think this is the standard for enough packages that we > shouldn't look at fixing it unless it's causing breakage. Agreed. Most (all?) of this stuff came from JPackage and there's little point in breaking compatibility/naming. Andrew -- Fedora-packaging mailing list Fedora-packaging(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging

1 0

Java guideline inconsistency
by Jussi Lehtola 09 May '09

09 May '09

Hi, there seems to be an inconsistency with the Java guidelines: http://fedoraproject.org/wiki/Packaging/Java http://fedoraproject.org/wiki/Packaging/Java#Jar_file_naming states that if the package only contains a single .jar file it should have the same name as the package, but the ant and maven spec file templates install .jar files as cp -p [build path to jar] \ $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar Also, I find it a bit inconsistent that java packages don't have to have a java- prefix as python, perl, php and so on packages have to. -- Jussi Lehtola Fedora Project Contributor jussilehtola(a)fedoraproject.org

4 7

Pre-review Gudelines
by Toshio Kuratomi 09 May '09

09 May '09

FESCo approved a request brought by rel-eng to allow a small set of packages to be checked into cvs and built only into a side tag before they pass review. Once they are building and brought up to standard, they would be put up for a full review and only then be built for the distribution. FESCo did say that there were certain review criteria that should be met before the packages could even get to that initial step of being checked into cvs and built for the side tag. They mentioned Not-from-source checks and legal issues as being in this category. We need to decide if there are additional Packaging Guidelines that need to be followed in order for the packages to pass prereview and push that recommendation to FESCo. It's also our job to document what those Guidelines are. I've made a start with this page: https://fedoraproject.org/wiki/Pre-review_Guidelines_(draft) It lists these Guidelines: * Licensing:Main * Packaging:LicensingGuidelines * Packaging:SourceURL * Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries * Packaging:Guidelines#Duplication_of_system_libraries The main concerns that I think we're trying to protect against are: 1) Is it legal for Fedora to distribute this package? 2) Reducing the chances that the package is going to do something that could cause issues for the build system. A third concern that I have but depends on whether the packages in the side tag will be moved over to the dist tags or if they will be rebuilt fresh in the dist tag is: 3) Protecting the toolchain from being built with malicious code. If the packages are going to be rebuilt fresh with our existing toolchain after a full review is done, then this wouldn't be a big issue to me as the full review either will or will not catch it as normal. If the packages built into the side tag will be moved over to the dist tag (or simply added as a buildroot override for the dist tag) in order to bootstrap the new packages then I would be concerned. fnasser, do you know if you guys need bootstrapping or will things be built fresh? -Toshio

8 14

Broken DistTag link in NamingGuidelines
by Todd Zullinger 08 May '09

08 May '09

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#DistTag says "please refer to the DistTag documentation..." but the DistTag text is not a link to http://fedoraproject.org/wiki/Packaging:DistTag, which makes it harder for folks to find the needed DistTag docs. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wedding is destiny, and hanging likewise. -- John Heywood

2 2

php firebird extension
by Philippe Makowski 06 May '09

06 May '09

Hi, Firebird (SQL relational database management system) will be soon packaged for Fedora I wanted to see if it is possible to add firebird exension to PHP The Mandriva package for this only do the following : %global modname firebird %global dirname interbase %global soname interbase.so %global inifile 42_%{modname}.ini Summary: Firebird database module for PHP Name: php-%{modname} Version: 5.2.6 Release: 0%{?dist} Group: Development/Libraries URL: http://www.php.net License: PHP License Source0: %{modname}.ini BuildRequires: php-devel >= 5.2.0 BuildRequires: firebird-devel Provides: php-interbase = %{version}-%{release} BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot %description This is a dynamic shared object (DSO) for PHP that will add Firebird database support. %prep %setup -c -T cp -dpR %{_usrsrc}/php-devel/extensions/%{dirname}/* . %build %serverbuild phpize %configure2_5x \ --with-libdir=%{_lib} \ --with-interbase=%{_libdir}/firebird but with Fedora it fails, it seems that php-devel don't have all PHP sources and cp -dpR %{_usrsrc}/php-devel/extensions/%{dirname}/* . don't work

4 3

Package-internal static linkage
by Ville Skyttä 04 May '09

04 May '09

Hello, Do the "no static linking" rules apply equally also to cases where the lib and the executable packaged are from the same package build? I'm packaging xz and intend to ship only shared libs, executables and devel files as usual, but upstream likes to link the executables statically with the rationale (liblzma comes from the same package, linkage would be done against the non-shipped static liblzma created during the build): ## Always link the command line tool statically against liblzma. It is ## faster on x86, because no need for PIC. We also have one dependency less, ## which allows users to more freely copy the xz binary to other boxes. It's easy enough to change this and link the executables dynamically, and I haven't bothered to get any numbers to check the upstream claim. But I suppose the primary security reason against static linkage doesn't really apply that much when the executable and the lib are results from the same package build, so I thought I'd ask if there are strong opinions on whether this would be a valid exception to the no static linkage guideline or not (none here).

4 7

Macro question for rpm gurus
by Gagadget 04 May '09

04 May '09

Dear listers, BIND has a version numbering system like this : Major.Medium.Minor-Ppatchlevel, with -Ppatchlevel only exists if patchlevel > 0. For instance, the source are named like that : bind-9.5.2-P2.tar.gz bind-9.6.0-P1.tar.gz bind-9.2.9.tar.gz I try to define a generic spec file for BIND packaging, here is what I did : %define VERSION 9.6.0 %define PATCHVER 1 [ ... ] %if %{PATCHVER} Source0: ftp://ftp.isc.org/isc/bind9/%{VERSION}-P%{PATCHVER}/bind-%{VERSION}-P%{PATC… %else Source0: ftp://ftp.isc.org/isc/bind9/%{VERSION}/bind-%{VERSION}.tar.gz %endif It works, but I'd like to know if there is a more recursive way to avoid if/else ? Using "?" macro or something like that ? Regards, Gael.

4 7

ruby gem and library in C and debuginfo
by Dan Horák 30 Apr '09

30 Apr '09

Hi, I am doing a review for a ruby gem package that includes a library written in C (https://bugzilla.redhat.com/show_bug.cgi?id=497640) and there are problems with proper generation of the debuginfo package. It cannot find the source files, because the paths in the debugsources.list contains the "ext/<libname>" part twice and that's wrong. + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /home/dan/rpmbuild/BUILD/rubygem-RedCloth-4.1.9 extracting debug info from /home/dan/rpmbuild/BUILDROOT/rubygem-RedCloth-4.1.9-3.fc10.x86_64/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/redcloth_scan.so cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c.rl: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_inline.c: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_inline.c.rl: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_scan.c: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_scan.c.rl: Cannot stat: No such file or directory Dan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2009