Changing default paths for mono packages
by Christian Krause
Hi,
After discussing the topic on mono-devel and with the upstream mono
developers I would like to run the following suggestions by the FPC:
The way how mono is packaged in Fedora is uncommon with respect to
mono's default search paths. The standard mono's libdir "/usr/lib" was
changed to "%{_libdir}" (which is "/usr/lib64" on x86_64).
Since this contradicts upstream's understanding of the directory
structure it causes lots of unnecessary work for the maintainers and
quite a couple of bug reports due to uncaught uses of these default
paths within the mono packages. Nearly every mono package must be
adjusted and so the majority of all patches for mono consists solely of
%{_libdir} "fixes". Since it looks like that upstream (not only
mono-core, basically all mono-based packages) does not agree to these
changes, non of these patches are accepted upstream nor do we get any
help from upstream if the issues are caused by Fedora's directory structure.
However, solving this issue (and reverting the change to mono's default
paths) would include to loose the ability to use
32bit parts of the mono stack in x86-64 - a feature which never worked
correctly and is not available for perl or python either.
Fedora's decision to change the default paths was based on a statement
from the mono developers a couple of years ago regarding the
architecture-independence of the mono assemblies. I have discussed this
topic with upstream again, and there was an agreement that
mono assemblies are treated as platform independent and so the original
reason to change the paths is not valid anymore.
Please see all details on the following wiki:
https://fedoraproject.org/wiki/User:Chkr/MonoMultiarchChanges
So my question to the FPC:
Do you agree with the suggested changes?
Best regards,
Christian
12 years, 11 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here is this week's change to the Fedora Packaging Guidelines:
---
The systemd guidelines on naming unit files have been amended to tell
packagers how to make compatibility symlinks for alternate service names
should their service have had a different name in the past.
http://fedoraproject.org/wiki/Packaging:Systemd#Naming
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to the Fedora Community, and all of the members of the FPC,
for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
12 years, 12 months
file /etc/sudoers from install of sudo-config-20110520-1.noarch conflicts with file from package sudo-1.7.2p1
by Calum
Hello all,
I am rolling my own RPM to provide the correct sudoers config for the
company where I'm working.
I want it to archive the existing /etc/sudoers, and put down the company's one.
However, when I install it, I get:file /etc/sudoers from install of
sudo-config-20110520-1.noarch conflicts with file from package
sudo-1.7.2p1
There are two ways around it that I know:
1. Put the file down as /etc/sudoers.companyname, and mv it in the %post
2. Unpackage sudo, modify, and re-package.
I prefer not to do 2, as that will require keeping a close eye on the
security errata of the package, and repackaging every time a new
version is released. I'd rather keep the upstream package untouched,
and just apply my config over the top.
1 works fine - however, it breaks the rpm -V functionality, which in
my eyes is a big plus point for using RPMs.
Installing with --replacefiles will work - however - however, I want
to deploy the package with Puppet, and it doesn't seem to allow
specifying that.
Is there a way to create the RPM in such a way that --replacefiles is
"built-in" to the RPM?
Is there any other way of doing this - so that rpm -V works?
Calum
13 years
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Here are the latest changes to the Fedora Packaging Guidelines:
---
A section has been added to the SysVInitScript guidelines covering the
optional situation where a package that uses systemd unit files as the
default also includes sysv initscripts in a subpackage:
https://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_ad...
---
The GIO scriptlets have been changed to not conditionalize the %post
invocation. This works around a multilib issue.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GIO_modules
---
The guideline that prohibits Fedora packages from using /srv has been
updated to better represent what the FHS has to say about /srv and to
clarify the expectations for Fedora packages which may be configured to
use /srv.
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directori...
---
It was brought to the FPC's attention that while the new Guidelines
covering MinGW packaging were technically correct, Fedora 16 did not yet
contain the necessary toolchain to support the new Guidelines, nor was
it clear that it would arrive in rawhide anytime soon.
Accordingly, the "old" MinGW guidelines were put back in place at:
https://fedoraproject.org/wiki/Packaging:MinGW
The "new" MinGW guidelines remain approved, but are not active and
packagers should not use them at this time. If/when the necessary
toolchain components are packaged in Fedora, these guidelines will be
re-enabled.
In addition, the current MinGW guidelines were improved slightly to
support the "new" SRPM naming standard. This is intended to prevent new
MinGW packages from having to be re-reviewed when the "new" MinGW
guidelines take effect.
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Kalev Lember, Matthew Miller, Michael Schwendt, and all
of the members of the FPC, for assisting in drafting, refining, and
passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~spot
13 years
How to add additional files in rpm
by Sunil_Gupta2＠Dell.com
Hello list,
I am trying to add some programs in rpm which are not the part of source package. I copied them in BUILD directory and mentioned them in
%install and %files section but rpmbuild -bb specfile always say
Install: cannot stat `iotestlist.sh`: No such file or directory
Am I missing something?
--Sunil
13 years
need LEGAL answer for gst-entrans
by Remi Collet
I'm on the way to review gst-entrans
https://bugzilla.redhat.com/show_bug.cgi?id=639518
This is a collection of plug-ins and tools for the GStreamer
It only requires liboil, but produce various plugins
/usr/lib64/gstreamer-0.10/libgstavidemux.so
/usr/lib64/gstreamer-0.10/libgstentrans.so
/usr/lib64/gstreamer-0.10/libgstmencoder.so
/usr/lib64/gstreamer-0.10/libgsttranscode.so
/usr/lib64/gstreamer-0.10/libgstvirtualdub.so
/usr/lib64/gstreamer-0.10/libgstyuv4mpeg.so
So, I must ask if there is any patent issue to include it in fedora
repository. I seems ok to me, but I'm not a expert in legal issue.
Remi.
13 years
.gitignore - what is supposed to be in it ?
by Development discussions related to Fedora
Hi, I noticed my .gitignore has:
rakarrack-0.5.8_Equinox.tar.bz2
/rakarrack-0.6.1.tar.bz2
/rakarrack-47245c3.tar.gz
The tar I expected to find 4724 is there, but so are the last few
versions. How does this work / is something going wrong ?
13 years
input on a conflicts case
by Kevin Fenzi
Greetings.
I'm looking at the supybot-gribble package (under review).
https://bugzilla.redhat.com/show_bug.cgi?id=693664
Currently it Conflicts: supybot.
It's not really falling under any of the current cases on
http://fedoraproject.org/wiki/Packaging:Conflicts
but I think it might be another case to add next to compat packages.
Background:
supybot is a irc bot written in python. It's already in Fedora.
Development is very slow. Currently many of the database functions in
it don't work because they still haven't switched from sqlite1 for
example. We also have several plugins that use it.
supybot-gribble is a blessed rapid development fork. Changes here are
fast paced and much more current. Once patches here look good and
stable they are submitted back to the main supybot branch. It's much
like a 'supybot-rawhide' or devel.
The two packages share the name and python tree files. Upstream has no
desire to rename things in supybot-gribble as this will make it harder
to fold changes back into supybot. There is no great need to run both
at the same time on the same machine.
In the review I suggested we just let them conflict and setup the
plugins so they would work with either (require /usr/bin/supybot). To
me this seems like an acceptable Conflicts case related to the 'compat
packages' case, except in this case it's 'newer/rawhide/ng version'.
Thoughts? Flames?
kevin
13 years
checking digest of one file
by Aaron Hanson
Hi All -
I can't figure out how to see and validate a specific file digest on my Fedora 14 system; I think I must be missing something simple.
Here's a quick example of what I'm trying to do:
[user@host]$ rpm -q --dump coreutils |grep bin/ls
/bin/ls 109208 1288784582 def61ac5ca608ba6f41eb08aa3eaa0b2274a67512938030830051d792fb3946e 0100755 root root 0 0 0 X
[user@host]$ sha256sum /bin/ls
881282512562ad22095371f0865be66f5424b7590e6c73eb15aae884cf9edd1c /bin/ls
Why doesn't the digest match? 'rpm' says the package is fine:
[user@host]$ rpm -V coreutils
[user@host]$ echo $?
0
Thanks.
Aaron
13 years
