Bug 477055

1) Looks like simply dropping it would be a regression (I am not talking about the contents of the spec templates): "rpmdev-newspec foo-fonts" and thus e.g. "emacs foo-fonts.spec" (for a nonexistent foo-fonts.spec) would no longer result in any fonts spec template being used.

Suggestion: make (symlink?) one of the templates from fontpackages to simply spectemplate-fonts.spec.  And add logic to rpmdev-newspec so that if one does "rpmdev-newspec foo-fonts-multi" (or -single), it knows that the -multi/-simple is not part of the package name and knows how to drop it appropriately.

2) Also, seems that what rpmdev-newspec would replace in the templates contained in fontpackages would no longer be the right thing; at least FONTNAME has changed to <FONTNAME> thus making the current replacing done by newspec pretty much useless.

Suggestion: either move back to plain FONTNAME or confirm that <FONTNAME> is the way it'll stay and I can adjust rpmdev-newspec accordingly.

3) The font spec templates in the fontpackages package use %{buildroot} syntax instead of $RPM_BUILD_ROOT which means rpmdev-newspec users can not easily opt to use shell style $RPM_... variables.

Suggestion: switch the templates to shell style $RPM_... variables (see rpmdev-newspec source for a full list); rpmdev-newspec -m (or NEWSPEC_PREFER_MACROS=1 in newspec's config files) will just continue to work that way.

4) Indentation of stuff after all Foo: tags is different from every other spec template that we have in rpmdevtools.

Suggestion: use same indentation levels and style (spaces only) as other spec templates in rpmdevtools for consistency and so that rpmdev-init.el will continue to do the right thing for those who prefer tabs over spaces for indentation.

I'm about to roll a new rpmdevtools release for all active distros for which I maintain it anyway so this would be a good time to make those changes (and e.g. take care of the spectemplate-fonts.spec file conflict if what's suggested in 1) is implemented).  But I'd like the above regressions be addressed before the transition.

I really know next to nothing about rpmdevtools, which is just a way to expose a spec template library to me, and it would have been great to have those remarks before the stuff was approved FPC and FESCO side and set in stone. (there was more than a month of public RFC phase)

Anyway

> 1) Looks like simply dropping it would be a regression…

There are two templates because reviews show there are two different use cases and they really are different patterns that do not fit in a single template

> 2) Also, seems that what rpmdev-newspec would replace in the templates
> contained in fontpackages would no longer be the right thing; at least
> FONTNAME has changed to <FONTNAME> 

I've tried to keep things consistent and put stuff to be replaced in brackets yes. If there is some other convention that would make it easier for you, please say so.

> 3) The font spec templates in the fontpackages package use %{buildroot} syntax
> instead of $RPM_BUILD_ROOT

The rpm devs have announced they'll be internalising buildroot creation so anything that tries to manipulate it from scripts is doomed mid-term anyway. And %{buildroot} is both valid and more consistent with the rest of the template

> 4) Indentation of stuff after all Foo: tags is different from every other spec
> template that we have in rpmdevtools.

I don't much care about this part and I doubt anyone will complain if I change it now

So I can change 4. For the rest if it's too much of a problem to you I can put the templates somewhere else in the filesystem. Bearing in mind that they are the new official Fedora templates, so the current rpmdevtools template will put induce packagers into doing stuff that will be blocked on review.

fontpackages-1.13 has been released an pushed rawhide-side with the requested indenting changes

(In reply to comment #2)
> There are two templates because reviews show there are two different use cases
> and they really are different patterns that do not fit in a single template

I understand that.  In comment 1 (the Suggestion: part to point 1) I outlined how rpmdevtools could adapt to that and do the right thing.  Could you comment on that?  This is really the crucial point - if it can't be sanely done, the rest of the points are pretty much moot as in that case there's not much at all rpmdevtools can do with the new font templates.

> > 2) Also, seems that what rpmdev-newspec would replace in the templates
> > contained in fontpackages would no longer be the right thing; at least
> > FONTNAME has changed to <FONTNAME> 
> 
> I've tried to keep things consistent and put stuff to be replaced in brackets
> yes. If there is some other convention that would make it easier for you,
> please say so.

All that matters is that rpmdev-newspec knows what to look for, and what it is looking for is a placeholder that can be assumed to be robustly sed-replaceable, and that it does not change between spec template revisions.  Please just confirm what it'll be (see Suggestion for point 2 in comment 1).

> The rpm devs have announced they'll be internalising buildroot creation so
> anything that tries to manipulate it from scripts is doomed mid-term anyway.
> And %{buildroot} is both valid and more consistent with the rest of the
> template

This has nothing to do with what sets the value of buildroot or how, and nothing to do with modifying it.  This is purely a stylistic issue which people have very strong opinions on: some people prefer to write specfiles using shell style variables, others rpm macro style.  For example whether one wants to write "rm -rf $RPM_BUILD_ROOT" or "rm -rf %{buildroot}" in specfiles.  We have support for honoring the user's preference in place in newspec if the templates are written using the shell style variable syntax - by writing them in macro style that preference is taken away (or additional code would need be added that does it the other way around, but I'm not sure if it can be robustly done).  Again, see Suggestion for point 3 in comment 1 for more details how this works currently.

> For the rest if it's too much of a problem to you I can put
> the templates somewhere else in the filesystem.

If we can't get rpmdevtools to do anything useful with the templates from fontpackages, it makes no sense to put them in rpmdevtools' dir structure, that'd just add confusion.  But I don't think there's a reason to go there - all it takes to support regressionless transition to the new font spec templates from rpmdevtools POV is outlined in questions in this comment (and comment 1) above.

To summarize, in a nutshell, what I could work from is if I get:

a) Confirmation that there are two font spec templates, /etc/rpmdevtools/spectemplate-fonts-{multi,single}.spec, and this is how it's going to stay in the foreseeable future.

b) Confirmation that the token in both of the above to be replaced with the font "basename" is exactly "<FONTNAME>" (sans quotes), and this is how it's going to stay in the foreseeable future.

Please provide answers to these ASAP, we're starting to be a bit in a hurry to get the next rpmdevtools out.

rpmdevtools-7.0-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/rpmdevtools-7.0-1.fc10

rpmdevtools-7.0-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/rpmdevtools-7.0-1.fc9

(In reply to comment #5)
> To summarize, in a nutshell, what I could work from is if I get:
> 
> a) Confirmation that there are two font spec templates,
> /etc/rpmdevtools/spectemplate-fonts-{multi,single}.spec, and this is how it's
> going to stay in the foreseeable future.

We will keep two templates as long as no one finds a clean way to address both use cases with a single template.

Realistically, since changing all the font packages in the distro to new guidelines is a lot of work, this won't happen before the F12 cycle (and probably not even then since no one has proposed new bright ideas so far)

> b) Confirmation that the token in both of the above to be replaced with the
> font "basename" is exactly "<FONTNAME>" (sans quotes), and this is how it's
> going to stay in the foreseeable future.

The templates are not intended to be changed now that the review phase is closed, the templates are documented in the wiki and many packagers have already converted to them (of course minimal bug-fixing will occur if people find problems but so far no one has complained about this part)

> Please provide answers to these ASAP, we're starting to be a bit in a hurry to
> get the next rpmdevtools out.

I hope those answers are satisfactory. I won't have much internet access before 2009 sorry :(

(In reply to comment #4)

> > The rpm devs have announced they'll be internalising buildroot creation so
> > anything that tries to manipulate it from scripts is doomed mid-term anyway.
> > And %{buildroot} is both valid and more consistent with the rest of the
> > template
> 
> This has nothing to do with what sets the value of buildroot or how, and
> nothing to do with modifying it.  This is purely a stylistic issue which people
> have very strong opinions on: some people prefer to write specfiles using shell
> style variables, others rpm macro style.  For example whether one wants to
> write "rm -rf $RPM_BUILD_ROOT" or "rm -rf %{buildroot}" in specfiles.  We have
> support for honoring the user's preference in place in newspec if the templates
> are written using the shell style variable syntax - by writing them in macro
> style that preference is taken away (or additional code would need be added
> that does it the other way around, but I'm not sure if it can be robustly
> done).  Again, see Suggestion for point 3 in comment 1 for more details how
> this works currently.

Is it possible for rpmdevtools to support replacing of the macro syntax too? Because I know many packagers use the templates as plain text templates too without use of rpmdevtools automation, and I'd really like the default not to be the shell variant in that case

I also have some opinions on this point :p

Of course it it's absolutely necessary for rpmdevtools I will change this. I didn't know you were performing post-processing on those parts.

rpmdevtools-7.0-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update rpmdevtools'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-11861

rpmdevtools-7.0-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update rpmdevtools'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11941

(In reply to comment #9)

> Is it possible for rpmdevtools to support replacing of the macro syntax too?

I suppose it's _possible_, but I'm not at all sure about the feasibility.  The shell style ones can obviously be used only in specfile constructs that are shell code, and replacing macro style ones with them in other sections would cause breakage, and implementing a real specfile parser is not something I even want to think about.  For spec templates that are shipped in rpmdevtools I can ensure that no breakage occurs but I can't do that for templates in other packages, such as these new font templates.

> Because I know many packagers use the templates as plain text templates too
> without use of rpmdevtools automation, and I'd really like the default not to
> be the shell variant in that case
>
> I also have some opinions on this point :p

Doh :P.  Well, even if it's not a "solution", I suppose educating them to take advantage of the rpmdevtools features wouldn't hurt.

> Of course it it's absolutely necessary for rpmdevtools I will change this.

It's not "absolutely necessary", but unless changed, it will be a small regression.  rpmdevtools 7.0 does not do macros->shell replacement, but it should take care of the -simple/-multi selection, always producing a foo-fonts.spec result, and <FONTNAME> replacement.

rpmdevtools-7.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

rpmdevtools-7.0-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.