Hello,
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].
The other thing is a minor patch that distinguishes variable from macro in the same template (attached)
Thanks,
Sarantis
[1] symlink rpmlint ticket http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/25
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.
Given that to my knowledge the relative symlink thing was never an official Fedora guideline, that chroots are considered broken by security people, that nowadays we have many virtualization options to achieve the same things without hitting absolute symlink and other security problems, and that no one complained during the review phase, I decided against overegineering and used simple absolute links.
I'm open to better solutions that avoid the warning as long as the result stays simple and stupid.
The other thing is a minor patch that distinguishes variable from macro in the same template (attached)
That looks harmless enough. If you feel that improves the template legibility I will make the change this week end (but only in rawhide)
Are you interested by commit access to the project?
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)
On Tue, Dec 30, 2008 at 04:37:15PM +0100, Nicolas Mailhot wrote:
That looks harmless enough. If you feel that improves the template legibility I will make the change this week end (but only in rawhide)
Fine by me. Although this change is readability only to a template that must be edited anyway by the respective packagers, so I see no harm in applying the patch to F9 and F10. Anyway no big deal.
Are you interested by commit access to the project?
Thanks, I'd be interested to help (time permitting of course) :)
-- Sarantis
-
Nicolas Mailhot -
Sarantis Paskalis