On 08/23/2011 12:47 PM, Thomas Moschny wrote:
> 2011/8/23 Orion Poplawski<orion(a)cora.nwra.com>:
>> See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation
>>
>> The environment module system allows users to modify their environment in a
>> predictable way, including setting LD_LIBRARY_PATH. However, this makes it
>> possible to break the modulecmd binary by putting an incompatible TCL (or
>> other) library earlier in the path. It would be great if modulecmd were made
>> impervious to such things, but I don't know the best or acceptable method to
>> do this. I'm guessing using rpaths would be the easiest.
>>
>> Thoughts/suggestions?
>
> Would something like this work?
>
> module ()
> {
> eval `/lib64/ld-linux-x86-64.so.2 --library-path ''
> /usr/bin/modulecmd bash $*`
> }
>
> (on a 64bit system; on a 32bit system it would need to use /lib/ld-linux.so.2).
>
> - Thomas
Hmm, I like this idea. I think it would protect the default system, but still
allow for end users to override it for some reason. It might even be
acceptable upstream.
I'm CC'ing the packaging list to get their thoughts.
--
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

In a package review recently I was asked to put brackets around all
macro usages. That is, writing
%{name}.desktop
rather than
%name.desktop
I personally think these superfluous brackets clutter the spec file
and reduce the readability. So when they are not necessary I always
omit them.
To me it somewhat strange that using brackets is more common than not
doing so. The situation is quite analogous to shell scripts. In
(ba)sh it is always ALLOWED to have brackets around variables, but
only rarely REQUIRED. Exactly as it is for macros in spec files. But
while you almost never see a shell script with brackets where they are
not needed, it is quite common in spec files.
Should the packaging guidelines have a ruling on this? There isn't
any as far as I can find. The closest I found was the choice between
%{buildroot} and ${RPM_BUILD_ROOT}, and in that case the only
requirement was consistency. Is consistency the only requirement in
the choice between %{name} and %name too? Or is the use of %{name}
with brackets actually required?

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!"

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.

Hi,
I am considering packaging a Mozilla extension, but I thought it best
to try to clarify some things beforehand. The only guidance (draft) I
found[1] doesn't seem to be followed by existing packages, but I agree
with it in principle. Until there are official guidelines, I have two
questions:
Is it acceptable to follow the draft guidelines, or should new
packages attempt to conform to the existing packages' (not quite
consistent) structure?
Is it appropriate to support any/all applications listed in the
install.rdf, even if they are not available in Fedora? (I don't see a
downside to this if the draft guidelines are followed, and it would
allow locally managed applications to take advantage of extensions
installed from RPMs.)
Thanks for any suggestions.
David
1. https://fedoraproject.org/wiki/User:Kalev/MozillaExtensionsDraft

Hi,
I was wondering about the use of cluttered email addresses in
changelogs. The first example of the guideline at
http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
uses an address of the type <joe at gmail.com>.
However, right after that it is said that one of the ensuing formats
must be used, and they all contain the explicit email address.
How should this guideline be interpreted?
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org