Re: [LONG] The fonts SIG irregular status report
As I wrote before, I don't think we could win a lot by automating. Well I tend to agree now: a good set of templates and rpm macros seems the right way to go. Jens ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: [LONG] The fonts SIG irregular status report
Le Mar 18 novembre 2008 11:33, Ralf Corsepius a écrit : On Tue, 2008-11-18 at 11:11 +0100, Nicolas Mailhot wrote: Le Mar 18 novembre 2008 09:32, Ralf Corsepius a écrit : Please review http://nim.fedorapeople.org/rpm-fonts/rpm-fonts-1.8-1.fc11.src.rpm and the other files in this directory, and propose ameliorations before we make it the backbone of our Fedora 11 font packages. I will vote against this proposal and this package. Rationale: All these macros do is causing further pollution of the rpm macros, break many details (try rpmbuild --define '_datadir /opt/foo' and add further cross distro-portability issues (Consider RHEL3 or rpm's from other distros). May be you recall the issues with Mandrake / Mandriva macros and with SuSE-macros, now you seem to be wanting to conduct Fedora into the same direction. What I've seen last year is: 1. packagers reinvent those independently (usually with bugs), so there's no drawbacks and lots of benefits in providing them a clean audited centralised version instead. 2. when you push too much logic in individual packages, this logic is not updated (when fc-cache arguments change) 3. the current guidelines are not easy enough for most packagers. If you don't agree with my solution to those problems please be constructive and propose another better one. -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: [LONG] The fonts SIG irregular status report
Le Mar 18 novembre 2008 11:33, Ralf Corsepius a écrit : I will vote against this proposal and this package. Rationale: All these macros do is causing further pollution of the rpm macros, break many details (try rpmbuild --define '_datadir /opt/foo' and add further cross distro-portability issues (Consider RHEL3 or rpm's from other distros). May be you recall the issues with Mandrake / Mandriva macros and with SuSE-macros, now you seem to be wanting to conduct Fedora into the same direction. Also if you would just look at it you'd see the whole thing is totally autonomous from the rpm package, and could be deployed as-is on other distributions releases (or plain other distributions) Taking of course into account all fontconfig versions are not equal and one needs to adapt the base package to the capabilities of the fontconfig provided by the distro he targets. -- Nicolas Mailhot ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: conf.avail, rpmlint and the FHS
I'm fine with this change. Next fontconfig release should happen sometime this winter I guess. I'll make this change in my tree that I will then make available to Keith for review and release. behdad Nicolas Mailhot wrote: Ping? Le dimanche 26 octobre 2008 à 21:30 +0100, Nicolas Mailhot a écrit : Hi all, When conf.avail was introduced in fontconfig we at Fedora mostly ignored it and let font packages install their fontconfig rules directly in conf.d http://fedoraproject.org/wiki/Packaging/FontsSpecTemplate (the exception being the fontconfig package itself who perforce followed the new conventions). Recent events made me revisit this point and try to heal the rift between fontconfig and font packages by following common conventions. http://fedoraproject.org/wiki/PackagingDrafts/Fonts_spec_template_correction_(fontconfig) In the course of the examination of this guideline change proposal, however, it was identified that conf.avail as currently designed causes our rpmlint package sanity check tool to emit errors. Those errors were ok for Behdad to ignore, but really not ok for general packaging guidelines we want to put into newbie packager hands. The core reason are that since we deploy policy through those fontconfig files, we absolutely do not want users to change them (they're free to un-reference the files in conf.d, or write their own fontconfig rules in different files, but we instruct rpm to stomp on old versions of our files on updates). Since we mark those files as non-modifiable (%config and not %config(noreplace) in rpm speak) rpmlint considers them as data, not configuration, and complains of their location under /etc. After thinking a bit about it I feel rpmlint is right — since we don't let users modify our fontconfig files they're not dynamic configuration, just static data users can choose to activate or not. We could of course add an exception in rpmlint just for conf.avail, but I'd rather have fontconfig be fixed to follow more closely the FHS. Exceptions ultimately pile on till you have a lot of cruft to clean up which is not my definition of fun. Can conf.avail and its contents be moved in /usr/share/something in the next version of fontconfig? See also: http://fedoraproject.org/wiki/Packaging/Minutes/20081021 Regards, ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: [Fontconfig] conf.avail, rpmlint and the FHS
Le mardi 18 novembre 2008 à 23:04 -0500, Jens Petersen a écrit : Can conf.avail and its contents be moved in /usr/share/something in the next version of fontconfig? So to make the discussion more concrete what is the suggested new path? /usr/share/fonts/conf.avail/ or /usr/share/fontconfig/conf.avail/ or ? (19:02:33) nim-nim: behdad: do you have an idea of the directory name you'll use, so I can put it in my macro package? (19:03:13) behdad: /usr/share/fontconfig/fonts.avail sounds right to me (19:03:23) behdad: specially that it's not used in any applications. (19:03:33) behdad: just as symlink targets. so I'm comfortable having fontconfig in the name (19:03:45) behdad: s/fonts.avail/conf.avail -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
