Packaging Reiser4
by Viji V Nair
Hi,
I would like to maintain reiser4 filesystem for Fedora. I have released the
same for Fedora 11, 64 bit. (
http://viji.fedorapeople.org/reiser4/F11/x86_64/). The same I want to
continue for all the upcoming release.
I am more interested to pack the same in the kmod standard, kmod-reiser4.
How can I go ahead, please advice.
Thanks
Viji
13 years, 5 months
Treatment of bundled libraries
by Ralf Corsepius
Hi,
during yesterday's FPC meeting, I voted "0" on this proposal:
https://fedoraproject.org/wiki/PackagingDrafts/Treatment_Of_Bundled_Libra...
<cite>
Packages with Bundled Libraries
Packages which contain bundled libraries (bundled libraries being
defined as libraries which exist and are mantained independently,
whether or not they are packaged separately for Fedora) must be handled
in the following manner:
* Bundled libraries (and/or their source code) must be explicitly
deleted during %prep. Build scripts may need to be patched to deal with
this situation. Whenever possible, the patching should be done in a way
to conditionalize use of the bundled libraries, so that it can be sent
upstream for consideration.
* It is not necessary to remove bundled libraries from the source
tarball unless there is a legal reason to do so
* Bundled libraries must NEVER end up in a package, even if they
are not used.
...
</cite>
As I won't be able to attend FPC meetings for the next 2 weeks, I was
asked to elaborate my vote here:
a) I perceive this proposal as unclear,
esp. wrt. a definition of "library".
It on one hand refers to "bundled binary libraries" (c.f. bootstrapping)
on the other hand, it refers to "bundled sources", but it is unclear
about bundled "libraries" of scripted languages (e.g. perl modules).
b) Conditionally building "bundled libraries" or parts from them
statically and linking against them statically, is a common way,
packages apply to escape from distributions shipping "old/insufficient"
versions of libraries.
I.e.
* mandating removing bundled libs will render packaging such packages
impossible, for distros which ship outdated/insufficient system
libraries, e.g. RHEL.
* "removing bundled libs" presumes "bundled libs" to be explicit.
In reality, this often is circumvented by "bundling a lib's files"
instead of a whole library.
I.e. this proposal is "blacklisting" one use case, but ignores another
use-case.
c) The proposal is explicitly demanding to "remove bundled libraries" in
%prep.
This is applicable without problems in some cases, with some efforts
attached to it in many cases, but it also is technically difficult to
implement in occasions (== error-prone and non-feasible).
Esp. in the latter cases, reality tells that it's often close to
impossible to "upstream" patches resulting from this, because certain
upstreams consider their "bundling" to be a feature and not to be a
"defect/bad design".
All in all, I agree with the objectives of this proposal but consider
this proposal to be too rough/un-cooked and to be
non-applicable/non-helpful.
It should be reworded to express the intentions behind it [1] and may-be
provide some "cookbook receipes".
Ralf
[1] "Re-use system-libs when ever possible".
13 years, 5 months
Need feedback on what constitutes "unbundling" a library
by Toshio Kuratomi
Greetings all, I've just opened a ticket for the FPC to define what
constitutes unbundling of a library:
https://fedorahosted.org/fpc/ticket/19
I'm going to paste the question here for discussion so that the FPC doesn't
make this decision in a vacuum.
When we deal with bundled libraries there's some ambiguity as to what
changes represent "unbundling". The changes may also differ between
programming languages.
First the options that I see in descending order of intrusiveness into the
package:
1. Delete the bundled libraries so they aren't installed by the binary rpm.
2. Make sure that if bundled libraries are present in the final installed
rpm that:
1. They are not used by the rpm package
2. They are marked private in some way so that they are not used by
other rpm packages
3. Make sure that if bundled libraries are present in the final installed
rpm that they are not used by the rpm package
Here's a case in a python application that bundles but does so compliant to
option #2:
https://bugzilla.redhat.com/show_bug.cgi?id=549405
In this case, upstream is providing pieces of the python stdlib that may not
be present on older versions of python. They mark the copied stdlib modules
as private by prepending with a leading underscore. When run on a new
enough python, the stdlib version of the module is imported rather than the
bundled version. As a tangent, this upstream has set up importing of the
modules so that they only have to make the check for stdlib modules in one
place. Other upstreams I've seen have made the check each place that the
module is imported which can lead to inadvertant use of the bundled module
if they forget to make the check when adding new code.
In the case of other languages, it depends on whether the languages provide
a means of conditionally loading the bundled library vs the system library
if present and if they provide a means of marking the bundled library
private. For C libraries, for instance, I think this would require storing
the module in a directory outside of the standard library path and also
dlopening the bundled library if the program fails to dlopen the library
from the standard library path. Writing this from scratch for C libraries
and passing it to upstream is likely to be much more intrusive than writing
something like the above python application does and hence less likely to be
accepted by upstream. Upstream for C applications normally accept patches
to choose the system library or bundled library at buildtime instead of
runtime so doing the runtime detection also doesn't make as much sense there
as for python.
I think that allowing option #2 or better makes sense (ie: making sure the
bundled library never shows up on the filesystem at all would also be
acceptable) but I'd like to hear other input. For instance, I'm willing to
bet that some packages are doing #3 at the moment and would need to be
further modified to also mark the libraries private. And I also wonder if
anyone feels that #2 is not sufficient. Please speak up and tell me what
you think.
-Toshio
13 years, 5 months
Need help with requires
by Orion Poplawski
plplot-tk packages some examples:
/usr/share/plplot5.9.7/examples/tk/tk01
/usr/share/plplot5.9.7/examples/tk/tk01.in
/usr/share/plplot5.9.7/examples/tk/xtk01.c
tk01 is a script to run the compiled xtk01.c and has:
#!/usr/share/plplot5.9.7/examples/tk/xtk01 -f
This generates a requires of /usr/share/plplot5.9.7/examples/tk/xtk01 which is
not present in the package.
I'd like to just get rid of the requires all together, but not sure how.
Should this be considered a bug at all in rpm, where it should limit script
interpreter dependencies to {/usr}/bin or some such?
Should I change it to something like (this doesn't work):
#!/bin/sh -c /usr/share/plplot5.9.7/examples/tk/xtk01 -f
Add a comment:
#Remove this line
at the top?
I can't use the filtering because this is an arch package with binaries.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 5 months
Is Conflicts acceptable in this case
by Remi Collet
I'm thinking of adding (for ocsinventory package) a :
Conflicts: perl-XML-SAX < 0.96
I cannot requires perl-XML-SAX >= 0.96, because
- this package doesn't requires perl-XML-SAX
- EL-5 have only perl-XML-SAX 0.14
When ocsinventory is installed (so, on EL-5 only) with
perl-XML-SAX-0.14, httpd eat all CPU :(
This seems related to
https://rt.cpan.org/Public/Bug/Display.html?id=29316
(patch is included in recent version)
If perl-XML-SAX were in EPEL, I could post a bug (RFE for update), but
it's a core RHEL-5 package...
Regards
Remi.
13 years, 5 months
Help with update issue
by Orion Poplawski
In paraview 3.8.0, %{_libdir}/paraview/paraview is a directory:
ls -l /usr/lib64/paraview/paraview
total 660
-rw-r--r--. 1 root root 4213 Aug 2 15:35 benchmark.py
-rw-r--r--. 2 root root 4202 Aug 2 16:20 benchmark.pyc
-rw-r--r--. 2 root root 4202 Aug 2 16:20 benchmark.pyo
....
In paraview 3.8.1, it is a file.
It fails to upgrade with:
Error unpacking rpm package paraview-3.8.1-2.fc14.x86_64
error: unpacking of archive failed on file /usr/lib64/paraview/paraview: cpio:
rename
paraview-3.8.0-4.fc14.x86_64 was supposed to be removed but is not!
Anything I can do to fix?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 5 months
Filtering Provides/Requires
by Orion Poplawski
Since this just came up and I'm working on an issue.
I need to filter from Provides/Requires everything in a file generated at the
end of the %install step. Is this possible with the tools listed in
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering?
It's not obvious to me if it is. I can't use %filter_provides_in because I do
need to capture some but not all requires from those items.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
13 years, 5 months
About libtool usage
by Sergio Belkin
Hi,
I've read on http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libra...
"Libtool archives, foo.la files, should not be included. Packages
using libtool will install these by default even if you configure with
--disable-static, so they may need to be removed before packaging. Due
to bugs in older versions of libtool or bugs in programs that use it,
there are times when it is not always possible to remove *.la files
without modifying the program. In most cases it is fairly easy to work
with upstream to fix these issues. Note that if you are updating a
library in a stable release (not devel) and the package already
contains *.la files, removing the *.la files should be treated as an
API/ABI change -- ie: Removing them changes the interface that the
library gives to the rest of the world and should not be undertaken
lightly."
Does that mean that we should not use libtool? What if I'd want to
build a shared library?
Thanks in advance!
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
Sergio Belkin -
13 years, 6 months
Packaging a postgresql cartridge
by Gianluca Sforna
I am packaging a library (rdkit.org) providing C/C++ and python
interfaces. Additionally, there is some code to create a Postgresql
cartridge with the same name (rdkit)
It seems we lack any guideline about packaging these, which is not
that bad considering I could only find another cartridge in the repos,
postigis.
However, I'd like to hear your opinion about how to name the
subpackage; I guess candidates would be:
1- postgresql-rdkit
2- rdkit-postgresql
3- rdkit-pgsql
right now I'm leaning toward 1- given that I found many instances of
3-style packages providing optional pgsql support for "name" and 2- is
not very different from 3-
thanks in advance
Gianluca
--
Gianluca Sforna
http://morefedora.blogspot.com
http://identi.ca/giallu - http://twitter.com/giallu
13 years, 6 months