perl packaging with oracle library
by Christopher Meng
Hi,
it's really tough for me to continue as I'm packaging a perl module
(DBD::Oracle), this is an important module for ora2pg, a very nice
database schema converter.
In order to install this DBD module I have to setup some PATH of
Oracle's product like Oracle Instant Client. That meens we must install
basic and devel rpm of OIC shipped by Oracle after clicking agree OTN
and blahblahblah... After installing these things we should also setup
environment variables like :
export ORACLE_HOME="/usr/lib/oracle/11.2/client/lib/"
export LD_LIBRARY_PATH=$ORACLE_HOME
ORACLE_HEADERS="/usr/include/oracle/11.2/client/"
It's really boring. Should I stop current work?
Thanks.
11 years
Static UIDs and GIDs
by Toshio Kuratomi
The FPC has recently been looking at a draft revision of the UID and Group
handling: https://fedorahosted.org/fpc/ticket/269
https://fedoraproject.org/wiki/User:Mitr/UsersAndGroups
This is an "interesting" draft on several fronts.
Historically:
* UID/GID allocation was one of the first major controversial
guideline that the FPC decided upon.
* The Guidelines specify that only dynamic UID and GID allocation is
supposed to be used and the Guidelines give instructions for how sysadmins
can adapt that to being static on a site-by-site basis by pre-allocating
the uids. Despite this, some packages have added their own static uids
and gids. This has lead to bugs.
What things have changed since then?
* New FPC members who might be able to either come up with something
different or would vote differently on this
* The 1000SystemAccounts[1]_ Feature of F16 has expanded the range of static
system accounts. However, the range is still miniscule -- we only have
from 0 to 200 and according to /usr/share/doc/setup-2.8.67/uidgid
approximately 160 of those have already been allocated
* As part of the 1000SystemAccount feature (IIRC), the allocation of system
dynamic accounts was changed so that system dynamic accounts were
allocated from the top of their range going down rather than from the
bottom. This means that on boxes freshly installed after F16 the static
range
* fedora-usermgmt was what prompted the original uid/gid guidelines. The
upstream author of that package has left fedora and there seems to be
activity to remove the need for it from all remaining packages in the
distro. This removes one of the sources of controversy that affected the
original guidelines.
.. [1]: http://fedoraproject.org/wiki/Features/1000SystemAccounts
What does the current draft propose?
* The draft needs some restructuring but the basic idea is that it would
add a way for packages to request a static uid/gid when they are created
but for that uid/gid to be overridden by the local sysadmin.
What will that gain us?
* If a sysadmin wants to modify the system id ranges for their site or
pre-allocates ids (for instance, to match what another distribution does),
they can do that with the soft-static allocation in the proposal.
Sysadmins cannot do that currently with packages which do not conform to
the Guidelines and allocate purely static uids and gids. Their systems
are highly likely to simply end up broken (Unable to install the packages)
* Out-of-the box sharing of files via a networked filesystem in a
homogeneous Fedora (and possibly RHEL) environment. Sysadmins will have
to modify the uids in heterogeneous networks because other distros have
different ranges for their system uids.
Things that we're considering adding to the draft:
* Having a group be the gatekeeper for allocating the static uid and gids
instead of that being solely the setup maintainer's responsibility. In
the past the setup maintainers have often added static uids and gids
without regard for whether they were needed or not. This leads to a
scarcity of uids and gids. Both FPC and FESCo have been proposed as this
group. I lean towards FPC since it is something where a lot of time has
to be spent figuring out whether there really is a need for a static uid
and then potentially instructing the packager as to why a dynamic uid is
just as fitting for their use case as a static one. Some others propose
FESCo as this is in the borderline between Guidelines and enforcement of
Guidelines (enforcement being FESCo's jurisdiction).
* Presently discussing whether static allocations should be done via
scriptlets in the setup package and the scriptlets for adding uids and
gids in the packages themselves will all be dynamic. Since the decision
of what uid and gid is allocated is centralized, making the implementation
actually be centralized has merit. It would also keep packagers from
cargo culting a static allocation from a different package by mistake.
However, it feels a little bit wrong. If someone can come up with a
technical reason not to do this, please speak up.
Some things I see us doing if we approve this revision:
* All packages using hard static uid allocation will be converted to soft
static allocation.
- Usually, when guidelines are updated there is no requirement that the
packages in the distro immediately adapt to the new guidelines. For
this guideline, hard static allocations are actually a latent bug that
sysadmins may not have reported but definitely could have run into.
* Packages doing hard static allocation that aren't listed in the setup
uidgid file should have their static allocation evaluated and be converted
to dynamic if appropriate.
* Some ways in which the useradd and groupadd scripts add dynamic system
uids and gids should be treated as bugs and fixed. (In particular that
they don't always allocate the highest available uid/gid in the SYS_UID
range) https://bugzilla.redhat.com/show_bug.cgi?id=924501#c9
We (the FPC) would love to have feedback on the draft and comments to help
iron out issues that it may cause. Ville: I am especially interested in
what you have to say as the author of our current uid/gid guidelines.
Thanks,
-Toshio
11 years
doxygen and copied font files
by Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=905255
(long bug -- comment 43 onwards is probably the place to start)
This package (open-vm-tools) uses doxygen to generate API
documentation. doxygen copies a font file from
'/usr/share/fonts/gnu-free/FreeSans.ttf' into the API docs directory,
and as a result [assuming you don't do anything else] the font file
gets copied into the final RPM as part of the %doc.
I don't quite understand how precisely this font file is used. The
CSS (doxygen.css) contains a reference to "FreeSans" as a font choice,
but I didn't know that browsers would use this reference to start
downloading *.ttf files from the same directory. Removing the font
file shows no obvious change to the doxygen docs when viewed in my
Firefox browser.
So question: Should the font file be removed? Left alone? Linked?
Something else?
Also there's a suggestion that this is a bug in doxygen:
http://lists.fedoraproject.org/pipermail/devel/2009-January/019434.html
although it was closed as NOTABUG (I don't think the doxygen packager
understood Nicolas Mailhot's bug report).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
11 years
Could and how we use jpackage repository to packaging?
by Chen, Wei D
Hi,
Our project is working on package our source code to follow redhat package standard, we want the rpm package we built could be accepted by fedora repository. One critical issue we found is some dependent binary (such as jaxws-tools.jar, jaxws-rt.jar and streambuffer.jar) cannot find relevant rpm package from fedora18 repository. Our source code cannot be built successfully without these binary, something weird is, we can find these jar binary from JPackage repository, and located in "glassfish-jaxws-repolib-2.1.3-8.jpp6.noarch.rpm" or " glassfish-jaxws-2.1.3-8.jpp6.noarch.rpm". So, my question is can we use JPackage repository in our rpm building process? How to use? Does this violate package standard? Why glassfish-jaxws related rpm package has been removed from fedora official repository? Is there any substitute solution? Great thanks for any of your suggestion.
Best Regards,
Dave Chen
11 years
Web server conf selection
by Christopher Meng
Hi,
I'm packaging a software which can be used under apache/nginx/lighttpd.
Should I choose httpd as default and put conf into /etc/httpd/conf.d or
just put everything in doc and let users choose?
Thanks.
*Yours sincerely,*
*Christopher Meng*
Always playing in Fedora Project
http://cicku.me
11 years
libtool rpath issues
by Daniel Pocock
Hi,
This has been discussed here before:
http://lists.fedoraproject.org/pipermail/packaging/2010-June/007187.html
but never really solved. Even if libtool is fixed, it's not clear to me
that existing packages will benefit until maintainers release new tarballs.
My reSIProcate upstream tarball is bootstrapped on Debian, so when I just do
tar xzf resip....
./configure && make
on Fedora x86_64 it uses rpath /usr/lib64. Same outcome when using
rpmbuild. The issue is discussed in more detail in the review request
for my package:
https://bugzilla.redhat.com/show_bug.cgi?id=892625
It would be really helpful for me and presumably other packages to
answer two questions:
a) out of the available hacks (such as those described in the earlier
discussion on this list), which one is currently recommended to solve
the issue in the existing package?
b) should libtool or something else change to avoid this problem in future?
This has also been raised in the libtool mailing list:
http://lists.gnu.org/archive/html/libtool/2013-04/msg00000.html
Regards,
Daniel
11 years
JFYI: snappy conflicts
by Michael Schwendt
This one is amazing! Just forwarding it for anyone interested in these
conflicts caused by too generic file names. ;-)
[...]
https://bugzilla.redhat.com/947640
Review Request: snappy - An open-source Gnome media player
| Actually, 'snappy player' collides with 'snappy compression/decompression
| library' already included in Fedora.
| There is also another 'snappy' binary provided by spice-gtk-tools package:
|
| $ repoquery --whatprovides /usr/bin/snappy
| spice-gtk-tools-0:0.15.3-1.fc18.x86_64
11 years
