define versus global !?
by Farkas Levente
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!"
12 years, 3 months
Systemd scriptlet comments
by Ville Skyttä
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.
12 years, 4 months
CA Certificates
by Orion Poplawski
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
12 years, 5 months
Kernel module spec file example
by Tvrtko Ursulin
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
12 years, 5 months
Re: [Fedora-packaging] gnome-shell-extension[s]
by Robert 'Bob' Jensen
----- "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 |
------------------------------------------------------------------------
12 years, 5 months
gnome-shell-extension[s]
by Robert 'Bob' Jensen
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 |
------------------------------------------------------------------------
12 years, 5 months
Query regarding header inclusions
by Ankur Sinha
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-LI...
[3]
http://java.net/projects/j3d-core/sources/svn/content/trunk/THIRDPARTY-LI...
[4]http://java.net/projects/j3d-core/sources/svn/show/trunk/src/native/ogl...
Thanks!
Regards,
Ankur
12 years, 6 months
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, 6 months
Re: [Fedora-packaging] Changing default paths for mono packages
by Christian Krause
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
12 years, 6 months
