Re: fontpackages template warnings
by Nicolas Mailhot
Le Mar 30 décembre 2008 16:37, Nicolas Mailhot a écrit :
>
> Le Mar 30 décembre 2008 15:29, Sarantis Paskalis a écrit :
>> Hello,
>
> Hi,
>
> Thank you for adapting your packages and providing feedback!
>
>> I am converting my font packages to the new guidelines and hit some
>> rpmlint warnings that appear to be template related. Specifically,
>> I
>> followed the /etc/rpmdevtools/spectemplate-fonts-multi.spec from
>> fontpackages-devel that creates absolute symlinks between
>> /etc/fonts/conf.d/$font.conf and
>> /usr/share/fontconfig/conf.avail/$font.conf
>> rpmlint moans about the absolute symlink and wants a relative one.
>> I
>> don't really have an opinion about that and could not find any
>> fedora
>> policy on this one [1].
>
> I didn't find a simple (for me and packagers) way to create relative
> symlinks here. Individual packages are not supposed to know the values
> of the directory macros since FPC asked for them in part to hide
> future value changes from individual packagers.
drat, should have read your link before commenting.
I'm not sure how ok it is to add a dep to symlinks for
fontpackages-devel. It looks harmless enough, but is this package even
in all our spins?
I suppose if I change the templates to use the symlinks command to
avoid the rpmlint warning, I need to notify FPC at least (even if it's
a minor change, it's still a guidelines change)
--
Nicolas Mailhot
14 years, 5 months
Usage of {_libdir} or {_lib} in noarch packages
by Karsten Hopp
I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages
which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output:
./firstaidkit-0.2.2-5.fc11.noarch.rpm
removed /usr/lib/firstaidkit
removed /usr/lib/firstaidkit/plugins
added /usr/lib64/firstaidkit
added /usr/lib64/firstaidkit/plugins
As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs
Here is the list of offending packages I've found:
Package Owner
------------------------
ntfs-config laxathom
firstaidkit msivak
terminus-font ndim
gdeskcal pfj
libopensync-plugin-synce awjb
cohoba tjikkun
gnome-schedule farnold
common-lisp-controller green
gcstar tian
revisor-cli jsteffan
jruby konradm
Can we make it a policy to not use _libdir or _lib in noarch packages, please ?
Karsten
14 years, 5 months
Font package splitting clarification
by Nicolas Mailhot
[Drat. I *knew* I had forgotten to spam one list]
Hi all,
Since the discussion on font package splitting rules seems to be
exhausted, and since no one stepped up with an obviously better proposal
than mine, I've queued the following FPC-side:
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rule...
I've tried to integrate all the exceptions that were brought up during
the discussion and that were consensual, and to separate the rules from
their rationale (so packagers in a hurry only need to read the first
part). I've ended up with four simple master rules that should not be
open to interpretation.
Best regards,
--
Nicolas Mailhot
14 years, 5 months
Ownership of /usr/share/gnome/help
by Jason L Tibbitts III
Can someone tell me what package should own /usr/share/gnome/help, or
if individual packages placing files there should own it? The latter
seems to be the case, but that doesn't make a whole lot of sense to
me. Is there any reason why /usr/share/gnome/help shouldn't just be
owned by filesystem? It already owns /usr/share/gnome.
Actually, it seems that several other packages own /usr/share/gnome
too, which probably begs for some bugs to be filed.
- J<
14 years, 5 months
"ratify"
by Andrew Overholt
Hi,
I couldn't find the meeting minutes for the most recent meeting but did
find that my proposed changes to the Eclipse plugin packaging guidelines
have the "ratify" status meaning they need to be run by FESCo. Does
this mean I need to be present during a FESCo meeting? If they're
passed by FESCo, will the changes be applied or do I need to do something?
Thanks,
Andrew
14 years, 5 months
guidelines for dbus services
by Matthias Clasen
In the light of the recent dbus debacle, I think it would be very good
to add a section about dbus services to the packaging guidelines.
As we have painfully learned, an incorrect policy file for a third-party
service can render the entire system bus unusable, or open it up to
everybody, so it is important that packagers pay attention to the dbus
policy files in their packages.
I don't have a concrete proposal right now, but Colin made a good start
at writing up some best practices here:
http://lists.freedesktop.org/archives/dbus/2008-December/010717.html
Matthias
14 years, 5 months
