"Explicit requires" and "requiring base package"
by Ville Skyttä
https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires
Packages must not contain explicit Requires on libraries except when
absolutely necessary. [...]
https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package
Devel packages must require the base package using a fully versioned
dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages
other than -devel should also require the base package using a fully
versioned dependency.
I think these two guidelines or their wording are more or less in conflict
these days. Most -devel packages do not "absolutely necessarily" need an
explicit dependency on the base package because rpm automatically adds soname
dependencies from symlinks in -devel to the corresponding shared lib in the
main/lib package. Ditto, many cases of other non-devel subpackages get
automatic lib soname dependencies to the main/lib package.
If the intent is to still require explicit deps like in "requiring base
package" even though there are automatic ones that would usually work, just to
be sure or for other reasons (possibility of compilation options, patchwork
that affects some internal subpackages but not other -devel/lib package
consumers), I think "requiring base packages" and "explicit requires" should
be cross referenced noting that this is an exception and those explicit deps
are indeed wanted.
If not, IMO "requiring base package" should be softened so that it requires
adding those explicit deps if no automatic ones are present, or just removed
because that'd be redundant with "explicit requires" and the rest of the
general dependency guidelines.
14 years
Packaging a game, need help with setgid security
by Ryan Rix
Hello group,
I have recently finished packaging the game IVAN (http://ivan.sf.net) for
Fedora 11:
Iter Vehemens ad Necum is a graphical roguelike game. It features advanced
bodypart and material handling, multi-colored lighting and, above all, deep
gameplay.
Like many roguelikes, it has a shared high score file and Bones files that
all users are meant to have their scores and final data written to. As a
result, the game is forced to run setgid games so that it has the rights to
write to /var/games/ivan/. While packaging this application, I got a lot of
help from some of the Fedora-KDE guys (hi Kevin, Ben) and they both
suggested I run this through Fedora Security SIG so that the game would
properly demote itself to non-setgid when it doesn't need to.
What is the proper channel to go about this? Should I just mail to the
security list? Should I put this package up for review beforehand/in the
meantime?
Thanks and Best,
Ryan Rix
--
Ryan Rix
(623)-826-0051
Fortune:
I'm DESPONDENT ... I hope there's something DEEP-FRIED under this
miniature DOMED STADIUM ...
http://hackersramblings.wordpress.com | http://twitter.com/phrkonaleash
XMPP: phrkonaleash(a)gmail.com | MSN: phrkonaleash(a)yahoo.com
AIM: phrkonaleash | Yahoo: phrkonaleash
IRC: PhrkOnLsh(a)irc.freenode.net/#srcedit,#teensonlinux,#plugaz and
countless other FOSS channels.
14 years
F-11 to F-12 transition
by Federico Hernandez
Now this might really be a newbie question but since I haven't maintained a
package that long yet I wonder how the transition now from F-11 to the
future F-12 works.
At what point can/must I check out a new CVS branch for F-12 of my package?
Will it be created automatically and all the packages in rawhide will move
by magic into F-12? Or do I need to request one via bugzilla?
Just wondering as I have never been around for this transition.
Greetings,
/Federico
14 years
bringing back to life a package (drivel)
by Andrey A.Kolov
Hi,
I would like to pick up a drivel (blog tool) package. It is in the list
of Retired packages since July 2008, as upstream was frozen at that
time. Now it seems alive, new version was released in April 2009.
I have contacted Paul W.Frields (who has maintained drivel in Fedora)
some time ago and he was keen to offer me maintaining this package.
I have checked on koji
(https://koji.fedoraproject.org/koji/taskinfo?taskID=1636387) and it
seems that old source are good enough to work on F11. My idea is to
bring old version to F11 now until I will finish accommodating new
sources. However, if this approach is not in line with rules and
policies I will be glad to follow your advises.
In any case, I will need some coaching. Is it possible for someone to
spend a little bit time with me on IRC (@fedora-devel, probably) to
understand further steps and actions ?
Thanking you in advance,
Andrey
14 years
how to force rpmbuild to use local libraries?
by Krzesimir Nowak
Hi,
I'm using Fedora 11, so all software in repository are stable ones, but
I'm developing a library using unstable versions of them (e.g. I have
now glibmm24 2.20, and I need it in version 2.21.3). I have those
unstable versions installed in my home directory (that is `~/usr/') and
I'm testing my library on them by using parallel environment provided by
`jhbuild shell'. I decided to build a package with rpmbuild, but it uses
`/usr/' path for everything (pkg-config files and such) even if I
execute it from my parallel environment, so building the package ends
quickly with message of unmet dependencies or in configure stage, when I
pass `--nodeps' option. My question is: is there a way to force rpmbuild
to use libraries in my home directory instead of those in `/usr/'?
Thanks for your help,
Krzem.
14 years
directory ownership in f-spot package
by Christian Krause
Hi,
Trying to fulfill all requirements regarding the directory ownership
described here
http://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership
has some implications for the f-spot package:
Please consider the following:
A package (here f-spot) provides a screensaver plugin for
gnome-screensaver in /usr/libexec/gnome-screensaver/ .
I see 3 possible solutions how to handle the directory ownership of
/usr/libexec/gnome-screensaver (which is already owned by
gnome-screensaver package):
1. The most trivial way would be to let f-spot depend on the
gnome-screensaver, don't own /usr/libexec/gnome-screensaver and just put
its executable there.
The drawback is that it may not be wanted that the installation of a
photo managing software requires the installation of a specific screensaver.
2. The f-spot package could make use of the exception and own
/usr/libexec/gnome-screensaver/ as well. However, the functionality-wise
f-spot's screensaver would still depend on gnome-screensaver. There
would be also the minor problem that the package would claim to provide
a functionality in various menus which would not be there if
gnome-screensaver would not be installed.
3. I could move screensaver part of f-spot into a sub-package. Only the
sub-package would then require gnome-screensaver. This would properly
satisfy all packaging requirements, but the users who want this
functionality must install the sub-package manually since they will
loose this feature during the update from the complete package to the
one which is split in two parts.
>From a packaging point of view I tend to choose option 3 despite its
drawbacks.
Would this be a good way?
Best regards,
Christian
14 years
Compat packages: Any best practices, rules, guidelines?
by Ryan Lynch
I'm trying to re-package a piece of software for Fedora. The catch is that
this software depends about 15-20 specific versions of external libraries
that Fedora ships, but only in a newer version. In several cases, this
conflict is a deal-breaker--i.e., other installed software relies on the
official Fedora library package/version, so I can't just replace the
official RPM outright with a site-specific version.
I would like to stay as close as possible to Fedora's packaging best
practices. Even if I don't submit the resulting packages to Fedora for
review, it's important to get as close to the guidelines as possible.
>From what I understand, the "right" way to package multiple parallel
versions of one library is the 'compat-*' convention (
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch18s02.html has an
overview). I took a look at the specs and manifests for a couple of
existing compat packages, and I think I understand the concept pretty well.
I think I can adapt the existing spec files and follow the conventions.
But I have a lot of questions, too, and I was hoping that anybody in the
know could help me.
* Is anything about the compat convention standardized, or a matter of
policy? I saw that the FESCO discussed about the issue, a while back, but I
feel like I may have missed something more recent.
* I can understand why large numbers of compat packages are frowned upon,
and 15+ compats to support one measly application seems excessive, even to
me. Is this the kind of thing that would torpedo a package review,
completely? Or is there room for discussion, given a commitment to improve
the situation (i.e., update the application) in time?
* What kinds of compat packages, and what specifically about them, are
considered bad? I've noticed that some compats don't appear to be included
in Fedora, like 'compat-python24'. It seems like a useful package, but I'm
seeing it in RPM Fusion--why didn't it pass review?
* In the future, what direction is Fedora taking the compat convention?
What kinds of long-term issues should I worry about, if I want to get ahead
of the curve?
If anyone can point me to existing resources on the compat subject, I would
appreciate the links, too.
Ryan B. Lynch
ryan.b.lynch(a)gmail.com
14 years
Meeting minutes
by Pierre-Yves Chibon
Hello,
I have been looking for the minutes of the last meetings of the
packaging comittee but I couldn't find them on the wiki [1] or on the
fedora-packaging or fedora-devel mailing list.
Are they available somewhere ? Did I look in the wrong place ?
Thanks in advance,
Best regards,
Pierre
[1] http://fedoraproject.org/wiki/Packaging:Minutes
14 years, 1 month
