packaging May 2010

packaging@lists.fedoraproject.org

30 participants
14 discussions

Fedora Packaging Committee Meeting - Wednesday May 12, 16:00 UTC
by Tom Callaway 12 May '10

12 May '10

The Fedora Packaging Committee will meet on Wednesday, May 12, at its regular time of 16:00 UTC, and in its regular location of #fedora-meeting. Here is the expected agenda: * CMPI Plugin Guideline: https://fedoraproject.org/wiki/PackagingDrafts/CMPIPlugins * Static Library PICness: https://fedoraproject.org/wiki/User:Ajax/Static_Library_PICness_Guidelines * Mark VCS in spec files: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal * Use %{_isa} to make hardcoded Requires Arch Specific: https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires * Correct existing definitions of RPM Macros in guidelines to match current reality: https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_opt… ===== If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know. The process for proposing a change to the Fedora Packaging Guidelines is documented here: https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedu… Also, to attempt to restore some sense of regularity to the FPC meetings, the FPC will also meet on the following days: * Wednesday May 26, 2010 - 16:00 UTC * Wednesday June 9, 2010 - 16:00 UTC * Wednesday June 23, 2010 - 16:00 UTC FPC members, please be sure to attend. Thanks, Tom "spot" Callaway, Fedora Packaging Committee Chair

7 12

whereis perl(ident) ?
by Franta Hanzlík 10 May '10

10 May '10

Hello, I'm not sure when I write to right list, please correct me if no. I just tried build RPM package for beta version of program calamaris ( http://cord.de/tools/squid/calamaris/calamaris-2.99.4.0.tar.gz ) RPM package was built successfully, but when I tried install it, rpm fail with message "perl(ident) is needed by calamaris-2.99.4.0-2.fc13.noarch" "rpm -qp --requires" output: config(calamaris) = 2.99.4.0-2.fc13 perl >= 0:5.002 perl(Carp) perl(GD::Graph) perl(GD::Graph::bars) perl(GD::Graph::colour) perl(GD::Graph::utils) perl(Getopt::Long) perl(Switch) perl(Sys::Hostname) perl(Time::Local) perl(calamaris::calAxestype) perl(calamaris::calAxestype3d) perl(constant) perl(ident) perl(integer) perl(lib) perl(strict) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 rpmlib(PayloadIsXz) <= 5.2-1 And "repoquery --whatprovides 'perl(ident)'" give me no output. I tried build & install this package both on Fedora 12 and Fedora 13, with same result. Although "rpm -U --nodeps ..." force install it and it will probably work, I would know why RPM want this capability and how it may be solved. Some my searching on Bugzilla on Internet wasn't successfull, my SPEC file contain only this "Requires" line: Requires: squid perl(NetAddr::IP) perl(GD::Graph) perl(GD::Graph3d) but result is same when this line isn't present. Probably rpmbuild has some mechanism for finding Perl package dependencies and list of required capabilities is created automatically. Of course, in calamaris programs isn't referenced any 'ident' object. Know someone how solve this problem? Thank in advance, Franta Hanzlik

1 1

Update for the GCJ section of Java Guidelines
by Aleksandar Kurtakov 07 May '10

07 May '10

GCJ AOT bits are mandatory parts of any Java packages according to current guidelines. There are at least 2 reasons to not require them: 1. GCJ has stagnated at Java 1.5 level and gcj bits require having GCJ installed even in cases when the package requires Java >= 1.6. Resulting in an installed but unusable for the given package JVM 2. GCJ AOT bits makes every package an arch specific one (when they are noarch in general)- resulting in slower package build, slower install/uninstall, bigger packages and etc. There are other benefits like - much more readable RPM spec files, using less resources on Fedora infrastructure. But the main benefit is for the users - we do not have to force them to install something they will never use. E.g installing eclipse-jdt drags gcj in but upstream is not supporting it and there is even a warning added to indicate that you're running gcj and it may not work as expected but gcj is still installed because of eclipse dependencies that have the gcj bits. This mail is by no means saying that there is no value in gcj. But gcj has a different usecases and shouldn't be thrown at every user. GCJGuidelines should be changed in such a way that they should indicate that you may add GCJ AOT bits to your package but this should not result in mandatory installation of GCJ (e.g. by making the gcj aot bits a separate subpackage auto-generated like the debug packages, but this is up to the people interested in gcj to solve). We simply don't have to force users to install a non-default and less feature full JVM in order to use our packages with another JVM. Regards, Alexander Kurtakov

4 7

create a wrapper installer
by MGandra＠diskeeper.com 06 May '10

06 May '10

Hi I have an rpm package for installation. Before I install I should display the License Agreement and when the user accepts it then I should install the package. I know we don't have user interaction in rpm, what I am looking at is how to create an wrapper so that I can present this license agreement and then ask the user to agree it and if he says "Yes" or "y" I can continue to install. I have seen programs like "jdk-6u18-linux-i586-rpm.bin" and other which are able to do this. We will just change the file to exectable and then run it. Can someone help me on how to do that or any pointers? Thanks Madhukar

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging May 2010