packaging June 2011

packaging@lists.fedoraproject.org

14 participants
9 discussions

define versus global !?
by Farkas Levente 19 Aug '11

19 Aug '11

hi, sorry for cross posting but may be someone on the packaging/rpm side can help me. i'm getting really angry about the debug packages:-) does anybody who can tell me the real reason of why: ------------------------------------ %define __debug_install_post %{mingw_debug_install_post} ------------------------------------ works why ------------------------------------ %global __debug_install_post %{mingw_debug_install_post} ------------------------------------ not? imho if i can know the answer to this question i can solve my only remaining issue with generated spec file for mingw. if why this in the spec file working: ------------------------------------ %define __debug_install_post %{mingw_debug_install_post} ------------------------------------ while this not: test: ------------------------------------ echo "%define __debug_install_post %{mingw_debug_install_post}" ------------------------------------ and in the spec file: ------------------------------------ %global test sh /tmp/test %{expand:%(%{test})} ------------------------------------ ??? the same thing is working for all other macro except for __debug_install_post. thanks in advance. regards. -- Levente "Si vis pacem para bellum!"

5 7

Systemd scriptlet comments
by Ville Skyttä 09 Aug '11

09 Aug '11

Some comments on systemd scriptlets at http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd 1) I don't think the versioned trigger logic will work too well at all in the (not that rare) cases where the previous distro had sysv scripts and one does a version bump in the previous distro - the trigger in the next one will no longer run on distro upgrades because of the versioning. Wouldn't it work better to just drop the version from the trigger altogether, and instead check if the old init script exists? For example: %triggerun -- httpd [ -e %{_initddir}/httpd ] || exit 0 # rest of the migration stuff goes here 2) Cosmetic: there are unnecessary '|| :'s sprinkled in the scriptlets, only the final exit status of a script has any effect. 3) More or less cosmetic: why hardwire absolute paths everywhere? The vast majority of other scriptlet snippets don't do that.

6 22

CA Certificates
by Orion Poplawski 24 Jun '11

24 Jun '11

I came across https://fedoraproject.org/wiki/PackagingDrafts/Certificates while trying to figure out how best to manage adding our private CA certificate to openssl's list of CA certificates. Unfortunately it appears that currently openssl only uses the single file /etc/pki/tls/cert.pem. This makes it hard to add one's own CAs and still get updates. Has there been any progress in this area? Any hope of a /etc/pkg/tls/cert.d/ directory where you could drop CA certs? -- 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

1 0

Kernel module spec file example
by Tvrtko Ursulin 21 Jun '11

21 Jun '11

Hi all, I am trying to find a working example of a spec file for packaging/building the most straightforward type of a kernel module for F15. Things I can find online seems either out of date, not working (possibly because being out of date), or depending on rpmfusion repositories. I also don't quite understand the kmodtool situation but that is not important at the moment. My main question is how to do it under plain F15? Many thanks, Tvrtko

2 1

Re: [Fedora-packaging] gnome-shell-extension[s]
by Robert 'Bob' Jensen 16 Jun '11

16 Jun '11

----- "Pierre-Yves Chibon" <pingou(a)pingoured.fr> wrote: > Some reviewers already tried to harmonize this: > https://bugzilla.redhat.com/show_bug.cgi?id=710386#c1 > > Using this approach: > """ > These extensions were built as subpackages of the main package > "gnome-shell-extensions", and so named > "gnome-shell-extensions-<foo>", > as defined in the guidelines. > It seemed logical to me to refer to "third-party" extensions under > the > name "gnome-shell-extension-<bar>", since the package would provide > only > one extension "a priori". Maybe we'll need to specify guidelines for > such extensions, becoming more numerous. > """ > (see comment 3 of the same bug report). > > This sounds like a valid approach to me. > A single element is not plural. End users are not going to know the difference between the "subpackages of the main package" and third party extensions, until this moment I did not so I had to look in to it myself. It seems the the "extensions" name is coming from the git repo where gnome has multiple extensions stored/developed. On the GnomeShell Extensions[1] page it describes the "gnome-shell-extension-tool" again a single extension with out the plural name. [1] https://live.gnome.org/GnomeShell/Extensions -- Bob ------------------------------------------------------------------------ | Robert 'Bob' Jensen || Fedora Unity Founder | | bob(a)fedoraunity.org || http://fedoraunity.org/ | | http://bjensen.fedorapeople.org/ | | http://blogs.fedoraunity.org/bobjensen | | http://www.facebook.com/rpjensen | ------------------------------------------------------------------------

1 0

gnome-shell-extension[s]
by Robert 'Bob' Jensen 16 Jun '11

16 Jun '11

I have seen some of the GNOME Shell extensions in the repos with the names gnome-shell-extensions and others with gnome-shell-extension. A naming standard should be established, I would suggest that each package contains a single extension, so the name sans "s" would be most correct. In the future if a meta package was created to be calling multiple extensions then "extensions" would be more correct. -- Bob ------------------------------------------------------------------------ | Robert 'Bob' Jensen || Fedora Unity Founder | | bob(a)fedoraunity.org || http://fedoraunity.org/ | | http://bjensen.fedorapeople.org/ | | http://blogs.fedoraunity.org/bobjensen | | http://www.facebook.com/rpjensen | ------------------------------------------------------------------------

3 2

Query regarding header inclusions
by Ankur Sinha 08 Jun '11

08 Jun '11

Hi folks, I need to package j3d-core[1]. The source includes a few headers that fedora packages already provide. Is it OK to let them be or do I need to get rid of these and make use of the ones that fedora packages provide? The licenses are here[2][3]. The mention the included third party headers as well. If I need to remove them, can I simply symlink the fedora provided headers here? Or do I need to edit the build system to make it point to them? If you look at the source folder here[4], it has separate build files for each platform/arch, so editing the build files would be a little difficult. I've also noticed that multiple packages provide the headers. How does one know which of these is the required one please? > [root@ankur root]# repoquery -f */include/*/glext.h > mesa-libGLES-devel-0:7.11-0.9.20110509.0.fc15.i686 > mesa-libGLES-devel-0:7.11-0.11.20110525.0.fc15.i686 > xorg-x11-drv-nvidia-173xx-devel-0:173.14.30-1.fc15.x86_64 > mingw32-w32api-0:3.15-2.fc15.noarch > gtkglext-devel-0:1.2.0-14.fc15.i686 > chromium-debuginfo-0:12.0.718.0-1.fc15.x86_64 > xorg-x11-drv-nvidia-173xx-devel-0:173.14.30-1.fc15.i686 > mesa-libGL-devel-0:7.11-0.9.20110509.0.fc15.i686 > mesa-libGL-devel-0:7.11-0.11.20110525.0.fc15.i686 > mesa-libGL-devel-0:7.11-0.9.20110509.0.fc15.x86_64 > mesa-libGL-devel-0:7.11-0.11.20110525.0.fc15.x86_64 > mesa-libGLES-devel-0:7.11-0.11.20110525.0.fc15.x86_64 > gtkglext-devel-0:1.2.0-14.fc15.x86_64 > mesa-libGLES-devel-0:7.11-0.9.20110509.0.fc15.x86_64 > [root@ankur root]# [1]http://java3d.java.net/ [2] http://java.net/projects/j3d-core/sources/svn/content/trunk/THIRDPARTY-LICE… [3] http://java.net/projects/j3d-core/sources/svn/content/trunk/THIRDPARTY-LICE… [4]http://java.net/projects/j3d-core/sources/svn/show/trunk/src/native/ogl?r… Thanks! Regards, Ankur

2 1

Changing default paths for mono packages
by Christian Krause 03 Jun '11

03 Jun '11

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

6 12

Re: [Fedora-packaging] Changing default paths for mono packages
by Christian Krause 03 Jun '11

03 Jun '11

Hi, On 06/01/2011 08:13 AM, Paul F. Johnson wrote: >>> The point was that hardcoding /usr/lib is always wrong. If they're arch >>> dependent, they should be in %{_libdir}. If not, /usr/share. So we >> >> Why? ;-) The FHS uses the following definitions: >> >> /usr/lib : Libraries for programming and packages >> /usr/share : Architecture-independent data > > I think that page needs updating for /usr/lib otherwise /lib64 is pretty > pointless! /usr/lib64 is mentioned in the next section: /usr/lib<qual> : Alternate format libraries (optional) > Upstream for many many year have been saying that as mono assemblies > (actual programmes such as monodevelop rather than the gmcs compiler > etc) should be placed in %{_datadir} as they are not arch (or even > operating system) specific. I think Toshio made a good point here: we have to distinguish between a) the fact whether a library or an executable is arch-dependent or not and b) whether, in case of arch-independence, the files should be placed in /usr/lib or /usr/share For a) seems to be the agreement that C# assemblies are arch independent. Regarding b) I'm convinced that it is well within the definition of the FHS to place arch-independent libraries into /usr/lib. Sure, /usr/share must only contain arch-independent files, but this does not mean, that all arch-independent files must go into /usr/share. ;-) Regarding the use of %{_datadir}: Do you have any reference when upstream explicitly asked for that? At least their response to my question was quite clear to use the paths defined by upstream (which is /usr/lib). > I've always been of the opinion with mono that upstream seriously don't > know where they want to put things. In some cases the automake/conf bits > point to %(libdir) macro and then in the code itself, it's hard coded > to /usr/lib AFAIK I see mostly fixes on their side changing %{_libdir} to %{prefix}/lib. So it looks like that upstream treats the usage of %{_libdir} as a bug. > We do it right. Eventually others will follow. Hm, I don't believe that upstream will ever adapt to Fedora's way of packaging mono.... Best regards, Christian

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

packaging June 2011