----- "Tom "spot" Callaway" tcallawa@redhat.com wrote:
The draft is available here: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% 282009-01-13%29
Sorry but this is not a good idea IMO. It requires 119 binary font packages in rawhide to be renamed, a number of which are referenced by a number of other packages in the distro.
It also makes it hard for people to work out what the source package name is.
What is so bad about the current fonts package naming convention "name-fonts-face"?
Jens
Anyway, to get the ball rolling:
1. I've pushed an updated fontpackages release on rawhide that takes into account FPC naming preferences
2. Packages with only a single font family inside should be unaffected by this change (they still build the same)
3. Packages with multiple font families inside need to be changed slightly to the new spec template. Basicaly a subpackage for foo font family was declared before with
%package foo ... %description foo
And need to use now
%package -n %{fontname}-foo-fonts ... Obsoletes: %{name}-foo < thisversion-thisrelease
%description -n %{fontname}-foo-fonts
The rest of the spec is completely unchanged, the macros behaviours where modified to take the new naming conventions into account (management of the transition for packages which have deps on needs to be worked out, but that should mainly concern dejavu only, and I've not touched it yet)
4. Non-font srpms with fonts subpackages that used
%package fonts-foo ... %description fonts-foo ... %_font_pkg -n fonts-foo ...
Need to be changed to
%package foo-fonts ... %description foo-fonts ... %_font_pkg -n foo ...
This stuff is only lightly tested in rawhide which is why I'm not going to push it to stable releases now ; if you want to play with it on non-rawhide systems install the rawhide fontpackages rpms on them. This is mainly to provide people a way to test by themselves what FPC requirements means instead of flooding the lists with mails.
Jens Petersen wrote:
----- "Tom "spot" Callaway" tcallawa@redhat.com wrote:
The draft is available here: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% 282009-01-13%29
Sorry but this is not a good idea IMO. It requires 119 binary font packages in rawhide to be renamed, a number of which are referenced by a number of other packages in the distro.
This could be taken care of by not renaming existing packages. What's your preference, to grandfather or not to grandfather?
It also makes it hard for people to work out what the source package name is.
Not unduly. Unlike our original feedback to Nicolas that a prefix of font- would be preferable, this groups the font binary subpackage close to the font package it comes from in any menu entries. That makes it relatively easy to find the source package.
What is so bad about the current fonts package naming convention "name-fonts-face"?
What is "name" in the above convention? In the original proposal handed to us, there was foundryname[-fontprojectname]-fonts[-fontfamilyname].
This seems like an odd format as there's two mandatory and two optional sections separated from each other. The sections also bounce back and forth between general and specific criteria. Pulling the font packages out of a list of rpms requires more coding and guesswork than when the -fonts is at one end or the other as well.
-Toshio
----- "Toshio Kuratomi" a.badger@gmail.com wrote:
This could be taken care of by not renaming existing packages. What's your preference, to grandfather or not to grandfather?
I am not sure: opinions seem to differ - also I am not completely clear how many of the packages need to be renamed anyway for foundry, etc. For package names that are changing anyway then this is less of an issue though of course there is still impact on the distro.
So it would be helpful to see a complete list of names for f10 vs proposed f11 names to get a clearer idea about the impact. Maybe even multiple columns comparing the proposals.
It also makes it hard for people to work out what the source package name is.
Not unduly. Unlike our original feedback to Nicolas that a prefix of font- would be preferable, this groups the font binary subpackage close to the font package it comes from in any menu entries. That makes it relatively easy to find the source package.
That is already mostly true of the current (f10) naming scheme, isn't it?
What is so bad about the current fonts package naming convention
"name-fonts-face"?
What is "name" in the above convention? In the original proposal handed to us, there was foundryname[-fontprojectname]-fonts[-fontfamilyname].
Yes, I guess I meant [foundryname-]fontprojectname-fonts[-fontfamilyname].
This seems like an odd format as there's two mandatory and two optional sections separated from each other. The sections also bounce back and forth between general and specific criteria.
"%Package family" is a lot simpler than "%Package -n foundry-font-family-fonts".
Pulling the font packages out of a list of rpms requires more coding and guesswork than when the -fonts is at one end or the other as well.
Well it just requires "*fonts*" rather than "*fonts". IMHO that is a small win and we are already used to the former glob anyway.
Jens
Jens Petersen wrote:
----- "Toshio Kuratomi" a.badger@gmail.com wrote:
It also makes it hard for people to work out what the source package name is.
Not unduly. Unlike our original feedback to Nicolas that a prefix of font- would be preferable, this groups the font binary subpackage close to the font package it comes from in any menu entries. That makes it relatively easy to find the source package.
That is already mostly true of the current (f10) naming scheme, isn't it?
AFAICS it's currently, maintainer's choice. Am I missing the current Guideline?
What is so bad about the current fonts package naming convention
"name-fonts-face"? What is "name" in the above convention? In the original proposal handed to us, there was foundryname[-fontprojectname]-fonts[-fontfamilyname].
Yes, I guess I meant [foundryname-]fontprojectname-fonts[-fontfamilyname].
This seems like an odd format as there's two mandatory and two optional sections separated from each other. The sections also bounce back and forth between general and specific criteria.
"%Package family" is a lot simpler than "%Package -n foundry-font-family-fonts".
Simpler is good but this just moves the complexity from the packager to the user. Why do you have "fonts" in the name at all? I assume it's so a person can tell by glancing at the package name that the package contains fonts? So it should be placed somewhere that highlights this fact -- either the beginning or end. What's the difference between a fonts-common and fonts-sans? Do they both contain fonts?
Pulling the font packages out of a list of rpms requires more coding and guesswork than when the -fonts is at one end or the other as well.
Well it just requires "*fonts*" rather than "*fonts". IMHO that is a small win and we are already used to the former glob anyway.
It depends on what you are doing. In yum, '*fonts*' might yield a correct result because you're depsolving. But selecting only packages containing fonts in the shell because you want to find the total size/number of font packages in the repo or make sure they all contain fonts would not work (for instance, they drag in the fonts-common subpackages).
-Toshio
Le Jeu 15 janvier 2009 02:33, Toshio Kuratomi a écrit :
Jens Petersen wrote:
----- "Tom "spot" Callaway" tcallawa@redhat.com wrote:
The draft is available here: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% 282009-01-13%29
Sorry but this is not a good idea IMO. It requires 119 binary font packages in rawhide to be renamed, a number of which are referenced by a number of other packages in the distro.
This could be taken care of by not renaming existing packages. What's your preference, to grandfather or not to grandfather?
I can't write font-packaging-support rpm macros that handle every possible naming variants, sorry. All the font packages in a release need to follow the same rules if you want spec files kept simple and understandable.
Regards,
packaging@lists.fedoraproject.org