Re: [Fedora-packaging] Java guideline inconsistency
by Fernando Nasser
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
14 years, 11 months
Re: [Fedora-packaging] Java guideline inconsistency
by Fernando Nasser
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
14 years, 11 months
Java guideline inconsistency
by Jussi Lehtola
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
14 years, 11 months
Pre-review Gudelines
by Toshio Kuratomi
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
14 years, 11 months
php firebird extension
by Philippe Makowski
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
14 years, 11 months
Package-internal static linkage
by Ville Skyttä
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).
14 years, 12 months
ruby gem and library in C and debuginfo
by Dan Horák
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
14 years, 12 months
