Re: Packaging Committee Meeting Summary (2010-02-03)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mercredi 03 février 2010 à 14:29 -0500, Toshio Kuratomi a écrit :

> We approved two guidelines:
> 
> SRPM Buildtime macros  https://fedoraproject.org/wiki/SRPM_Buildtime_macros
> For: 5 hansg, SmootherFrOgZ, tibbs, abadger1999, rdieter
> Against: 0

While I don't really see the need for
 out-of-spec macros for in %summary or %description text, rpm spec
format has this unfortunate property of lacking explicit end of section
markers.

So macros that would expand to other sections will be considered part of
%summary if they occur after a real summary and are not expanded. The
guideline text is not clear on whether this is allowed or not. If not we
have scores of packages to change fonts sig side. And I'll point out we
do not have the resources to, we've already spent more than a year going
through other packaging cleanups, have not finished processing all the
fonts in Fedora, and are unlikely to be ready for any other change short
term (looks like TEX cleanup will miss F13 like it missed F12, for
example)

The way we use macros is the cleanest solution I could find last year
without rpm changes. I don't like using macros to expand whole sections,
but rpm lacks proper spec templating support and I've not been
successful in convincing rpm devs to add it in the near future. Till
this changes, trying to avoid all the side-effects of macro expansion is
a lot of work, with little actual gains for Fedora users.

The actual issue is :
1. we always do the same processing (in %install and %post) on font
files
2. but a human needs to decide in which subpackage each font file will
go, and a human needs to write the subpackage summary/description (this
is impossible to automate). In an ideal world subpackages would not be
necessary, because upstream would always publish exactly the set of
files we need in each font package in a separate archive, but in the
real world upstreams do all kinds of strange inconsistent releases, and
our spec files are used to triage the resulting mess and break it in
clean units for our users.

What we want to declare in the spec file is

%package -n subpackagex
%summary
... usual evr tricks

%summary -n subpackagex
human description

%template(fonts) -n subpackagex
list-of-font-files-to-process-in-the-usual-way

With template a magic keyword that tells rpm to look at its font
template and add the appropriate content in the general %install section
and in the subpackage %post and %files
(for each file in the list, that exists after %build in the buildroot,
add those lines to the spec replacing the template variable with the
file name). And I say %install, %post and %files but we could use this
in other rpm sections too, those are just the most critical for us right
now.

Since current rpm is too dumb to be used this way %template(fonts) is
actually a standard macro rpm expands to new %post and %files sections
(and we get to type the same lines again and again in %install because I
could not handle this part at all through a macro). It's usually
declared just after the associated %summary since keeping all the stuff
associated with a subpackage in the same place limits human mistakes.

A side-effect, is that spec parsers that read the file in a buildroot
which is missing the package providing the macro, will sometimes think
the macro call is part of the subpackage %summary. This is unfortunate,
but I don't see how to avoid it without making another part of the spec
harder for us.

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux