1:29 p.m.
Commitee members present
abadger1999
hansg
tibbs
racor
rdieter
SmootherFrOgZ
Committee members absent
rathann
limburgher (technical difficulties)
spot (parental duties)
We approved two guidelines:
SRPM Buildtime macros https://fedoraproject.org/wiki/SRPM_Buildtime_macros
For: 5 hansg, SmootherFrOgZ, tibbs, abadger1999, rdieter
Against: 0
Emphasize correct SF.net SourceURL
https://fedoraproject.org/wiki/PackagingDrafts/SourceURL_sourceforge_down...
For: 5 hansg, rdieter, abadger1999, SmootherFrOgZ, tibbs
Against: 0
These now go to FESCo for approval.
The committee also voted to recommend no exception for some of the libraries
that wordpress bundles to fesco (the ones that are not heavily modified).
Committee will discuss what qualifies as a "functionally modified" version
of a library and whether that's acceptable this week on the packaging
mailing list and at next week's meeting.
"Recommend no exception for the list of non-heavily modified libraries"
For: 5 abadger1999, rdieter, tibbs, racor, SmootherFrOgZ
Against/abstain: 1 hansg had to leave before the vote was announced but while
present he semed to favour grandfathering in non-heavily modified
libraries that are not already packaged for Fedora.
The committee started voting on new Guidelines for python modules that
includes Guidelines for python3 but suffered network difficulties in the
middle of the discussion. This will ocntinue on the packaging mailing list
and hopefully be voted on later this week.
https://fedoraproject.org/wiki/PackagingDrafts/Python3
Current state:
For: 3 rdieter, tibbs, abadger1999
Against: 1 racor racor wants to have a note in the guidelines of when the
python-2.x package will be removed from Fedora. Other committee members
argued that this was 1) out of scope for the FPC (would be a packagr or
FESCo decision) and 2) impossible to know at this juncture as the uptake
of python3 among module authors is not yet very high -- that leads to no
one being able to port because their dependencies have not been ported.
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting/2010-02-03/fedora-meeting...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting/2010-02-03/fedora-meeting...
Log:
http://meetbot.fedoraproject.org/fedora-meeting/2010-02-03/fedora-meeting...
-Toshio
3:19 p.m.
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
3:28 p.m.
On Wed, 2010-02-03 at 22:19 +0100, Nicolas Mailhot wrote:
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.
So long as it doesn't disrupt what is viewed as the summary from the
srpm stored in Koji, I think you'll be fine.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:55 p.m.
Le mercredi 03 février 2010 à 13:28 -0800, Jesse Keating a écrit :
On Wed, 2010-02-03 at 22:19 +0100, Nicolas Mailhot wrote:
> 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.
So long as it doesn't disrupt what is viewed as the summary from the
srpm stored in Koji, I think you'll be fine.
Unfortunately, I dimly remember seing the macro call appear in the past
in the summary shown in packagedb or koji (don't remember the package
name, and it may not occur with new koji/packagedb versions). This is
purely cosmetic (the actual summary is fine, there's just a strange line
after it), but I could understand people not liking it. I'd gladly get
rid of the current macro hack if rpm made it possible.
--
Nicolas Mailhot
4:14 p.m.
On Wed, Feb 03, 2010 at 10:55:25PM +0100, Nicolas Mailhot wrote:
Le mercredi 03 février 2010 à 13:28 -0800, Jesse Keating a écrit :
> On Wed, 2010-02-03 at 22:19 +0100, Nicolas Mailhot wrote:
> > 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.
>
> So long as it doesn't disrupt what is viewed as the summary from the
> srpm stored in Koji, I think you'll be fine.
Unfortunately, I dimly remember seing the macro call appear in the past
in the summary shown in packagedb or koji (don't remember the package
name, and it may not occur with new koji/packagedb versions).
Easy to check, what's a package that does this macro directly after Summary:
or %description?
-Toshio
4:46 p.m.
Le mercredi 03 février 2010 à 17:14 -0500, Toshio Kuratomi a écrit :
On Wed, Feb 03, 2010 at 10:55:25PM +0100, Nicolas Mailhot wrote:
> Le mercredi 03 février 2010 à 13:28 -0800, Jesse Keating a écrit :
> > On Wed, 2010-02-03 at 22:19 +0100, Nicolas Mailhot wrote:
> > > 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.
> >
> > So long as it doesn't disrupt what is viewed as the summary from the
> > srpm stored in Koji, I think you'll be fine.
>
> Unfortunately, I dimly remember seing the macro call appear in the past
> in the summary shown in packagedb or koji (don't remember the package
> name, and it may not occur with new koji/packagedb versions).
>
Easy to check, what's a package that does this macro directly after Summary:
or %description?
adf-accanthis-fonts is probably the most recent "complex" font package
but I wouldn't vouch the declaration happens exactly in the same order
in all font packages. The general pattern is the same but packagers have
different tools and habits so slight variations exist.
--
Nicolas Mailhot
4:48 p.m.
Le mercredi 03 février 2010 à 23:46 +0100, Nicolas Mailhot a écrit :
Le mercredi 03 février 2010 à 17:14 -0500, Toshio Kuratomi a écrit :
> On Wed, Feb 03, 2010 at 10:55:25PM +0100, Nicolas Mailhot wrote:
> > Le mercredi 03 février 2010 à 13:28 -0800, Jesse Keating a écrit :
> > > On Wed, 2010-02-03 at 22:19 +0100, Nicolas Mailhot wrote:
> > > > 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.
> > >
> > > So long as it doesn't disrupt what is viewed as the summary from the
> > > srpm stored in Koji, I think you'll be fine.
> >
> > Unfortunately, I dimly remember seing the macro call appear in the past
> > in the summary shown in packagedb or koji (don't remember the package
> > name, and it may not occur with new koji/packagedb versions).
> >
> Easy to check, what's a package that does this macro directly after Summary:
> or %description?
adf-accanthis-fonts is probably the most recent "complex" font package
but I wouldn't vouch the declaration happens exactly in the same order
in all font packages. The general pattern is the same but packagers have
different tools and habits so slight variations exist.
Anyway here is one occurence of what I worried about in all its glory
http://koji.fedoraproject.org/koji/buildinfo?buildID=130814
--
Nicolas Mailhot
5:33 p.m.
On Wed, Feb 03, 2010 at 11:48:52PM +0100, Nicolas Mailhot wrote:
Le mercredi 03 février 2010 à 23:46 +0100, Nicolas Mailhot a écrit :
> adf-accanthis-fonts is probably the most recent "complex" font package
> but I wouldn't vouch the declaration happens exactly in the same order
> in all font packages. The general pattern is the same but packagers have
> different tools and habits so slight variations exist.
Anyway here is one occurence of what I worried about in all its glory
http://koji.fedoraproject.org/koji/buildinfo?buildID=130814
Yep.
So, while less than ideal from your standpoint of putting the definition of
the subpackage together with the call to the macro, does rearranging things
like this do the trick?
[Package info]
[subpackage info]
%prep
[prep stuff]
%build
[build stuff]
%install
[install stuff]
%_font_pkg -n 2 -f %{fontconf}-2.conf AccanthisADFStdNo2-*.otf
Since %_font_pkg is creating %files sections and %pre and %post sections,
that seems like both a valid workaround and where you'd look for those
declarations in a non-font package.
-Toshio
12:53 a.m.
Le mercredi 03 février 2010 à 18:33 -0500, Toshio Kuratomi a écrit :
On Wed, Feb 03, 2010 at 11:48:52PM +0100, Nicolas Mailhot wrote:
> Le mercredi 03 février 2010 à 23:46 +0100, Nicolas Mailhot a écrit :
> > adf-accanthis-fonts is probably the most recent "complex" font
package
> > but I wouldn't vouch the declaration happens exactly in the same order
> > in all font packages. The general pattern is the same but packagers have
> > different tools and habits so slight variations exist.
>
> Anyway here is one occurence of what I worried about in all its glory
>
> http://koji.fedoraproject.org/koji/buildinfo?buildID=130814
>
Yep.
So, while less than ideal from your standpoint of putting the definition of
the subpackage together with the call to the macro, does rearranging things
like this do the trick?
That would probably avoid the koji display problem but is sure to
introduce packaging bugs. The macro call has been put in this particular
place because experience shows that reduces human mistakes. It's never
easy to do back and forths between two parts of the same file, but in
this case they are compounded by the kind of syntax forced on us by the
use of a macro. Everything needs to be cramed on a single line. Any
syntax error and things fail without proper error messages (I've tried
to add some debug output. I caused mock build to stop dead). You can not
do as many calls as you want (like you can for %doc) or rpm will
complain of multiple %posts or %files for the same subpackage (without
telling you exactly which subpackage fails)
The choice that was made was to minimize human error risk at the expense
of some prettiness in koji. I'd do the same choice today in a blink. We
are severely limited what the tools can do, but trying to accomodate
tools at all costs results in undue human burden and lots of bad
packages. Humans have limits too.
--
Nicolas Mailhot
2:20 a.m.
Nicolas Mailhot wrote:
That would probably avoid the koji display problem but is sure to
introduce packaging bugs. The macro call has been put in this particular
place because experience shows that reduces human mistakes. It's never
easy to do back and forths between two parts of the same file, but in
this case they are compounded by the kind of syntax forced on us by the
use of a macro. Everything needs to be cramed on a single line. Any
syntax error and things fail without proper error messages (I've tried
to add some debug output. I caused mock build to stop dead). You can not
do as many calls as you want (like you can for %doc) or rpm will
complain of multiple %posts or %files for the same subpackage (without
telling you exactly which subpackage fails)
The choice that was made was to minimize human error risk at the expense
of some prettiness in koji. I'd do the same choice today in a blink. We
are severely limited what the tools can do, but trying to accomodate
tools at all costs results in undue human burden and lots of bad
packages. Humans have limits too.
Sorry, but the decision has been made, you have to put the macro where it
belongs. Something which expands to scriptlets and %files sections needs to
go where the scriptlets and %files sections belong, NOT in the Summary where
it will be wrong in the SRPM. The problem is that it's not only within Koji
that the unexpanded macros show up, but also in the shipped SRPMs!
Kevin Kofler
3:26 a.m.
On Thu, Feb 04, 2010 at 09:20:12AM +0100, Kevin Kofler wrote:
Nicolas Mailhot wrote:
> That would probably avoid the koji display problem but is sure to
> introduce packaging bugs. The macro call has been put in this particular
> place because experience shows that reduces human mistakes. It's never
> easy to do back and forths between two parts of the same file, but in
> this case they are compounded by the kind of syntax forced on us by the
> use of a macro. Everything needs to be cramed on a single line. Any
> syntax error and things fail without proper error messages (I've tried
> to add some debug output. I caused mock build to stop dead). You can not
> do as many calls as you want (like you can for %doc) or rpm will
> complain of multiple %posts or %files for the same subpackage (without
> telling you exactly which subpackage fails)
>
> The choice that was made was to minimize human error risk at the expense
> of some prettiness in koji. I'd do the same choice today in a blink. We
> are severely limited what the tools can do, but trying to accomodate
> tools at all costs results in undue human burden and lots of bad
> packages. Humans have limits too.
Sorry, but the decision has been made, you have to put the macro where it
belongs. Something which expands to scriptlets and %files sections needs to
go where the scriptlets and %files sections belong, NOT in the Summary where
it will be wrong in the SRPM. The problem is that it's not only within Koji
that the unexpanded macros show up, but also in the shipped SRPMs!
Why can't the following be used?
%{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
Since the macro is not really part of the Summary, there is no missing
information if it does not expand.
Btw. the guidelines looks incomplete. This is the second sentence:
| Because SRPMs are built without the package's BuildRequires installed,
| depending on macros defined outside of the spec file can easily lead to
| this issue.
But there is no real explanation of "the issue", e.g. the problem that
macros that are not really intended to build the packages description
are shown unexpanded in the description.
Regards
Till
4:49 a.m.
Le Jeu 4 février 2010 10:26, Till Maas a écrit :
On Thu, Feb 04, 2010 at 09:20:12AM +0100, Kevin Kofler wrote:
> Nicolas Mailhot wrote:
> > That would probably avoid the koji display problem but is sure to
> > introduce packaging bugs. The macro call has been put in this particular
> > place because experience shows that reduces human mistakes. It's never
> > easy to do back and forths between two parts of the same file, but in
> > this case they are compounded by the kind of syntax forced on us by the
> > use of a macro. Everything needs to be cramed on a single line. Any
> > syntax error and things fail without proper error messages (I've tried
> > to add some debug output. I caused mock build to stop dead). You can not
> > do as many calls as you want (like you can for %doc) or rpm will
> > complain of multiple %posts or %files for the same subpackage (without
> > telling you exactly which subpackage fails)
> >
> > The choice that was made was to minimize human error risk at the expense
> > of some prettiness in koji. I'd do the same choice today in a blink. We
> > are severely limited what the tools can do, but trying to accomodate
> > tools at all costs results in undue human burden and lots of bad
> > packages. Humans have limits too.
>
> Sorry, but the decision has been made, you have to put the macro where it
> belongs. Something which expands to scriptlets and %files sections needs to
> go where the scriptlets and %files sections belong, NOT in the Summary where
> it will be wrong in the SRPM. The problem is that it's not only within Koji
> that the unexpanded macros show up, but also in the shipped SRPMs!
Why can't the following be used?
%{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
In theory in can. In practice that will increase the number of human mistakes
since it is not a human-friendly syntax. Again my #1 objective is not to be
pretty but to have something that works user-side with the packagers we have.
(I'd like to have pretty srpms too but I'll settle with error-free rpms any
day)
Anyway I've taken the time to explain why the current wording is ambiguous (I
do not use macros in summaries, that rpm fails to see where the summary ends
is no fault of mine). I've taken the time to explain my problem (I need
something which is simple enough people do not spend their time adding and
correcting bugs induced by quirky rpm syntax). If the aim is not to find the
best compromise for everyone, but to play the 'too late, it's been decided,
just do it' game (though I respectfully point out no guideline is in effect
before FESCO approval) I'll play the 'compliance with 2010 guidelines is
planified after full-distro compliance with 2008 guidelines is done' game.
Some things are easy to take into account. This change is not, because it
depends on humans not making human mistakes (not like the define=>global
change that was 100% equivalent for humans). I don't see how the induced work
could even remotely be worth it. (remember, this is only about prettifying
summaries in srpms and koji no one but a tiny part of our user base will ever
look at).
If the objective is to make sure such macro call traces are eliminated from
summaries, and unless someone finds an actual case when someone needs to
display something looking macro calls in a summary, the correct and robust
solution is just to have rpmbuild zap those calls at srpm build time. But if
the issue is not worth the developer time to change rpm, it's certainly not
worth the time needed to fix it manually (and by fix I do not mean just a one
time sed run, I mean making sure this pattern is not reintroduced and
hand-holding all the packagers that will make new mistakes because the syntax
suddenly become more human-error-inducing).
--
Nicolas Mailhot
10:16 a.m.
On Thu, Feb 04, 2010 at 11:49:46AM +0100, Nicolas Mailhot wrote:
Le Jeu 4 février 2010 10:26, Till Maas a écrit :
> On Thu, Feb 04, 2010 at 09:20:12AM +0100, Kevin Kofler wrote:
>> Nicolas Mailhot wrote:
>> > That would probably avoid the koji display problem but is sure to
>> > introduce packaging bugs. The macro call has been put in this particular
>> > place because experience shows that reduces human mistakes. It's never
>> > easy to do back and forths between two parts of the same file, but in
>> > this case they are compounded by the kind of syntax forced on us by the
>> > use of a macro. Everything needs to be cramed on a single line. Any
>> > syntax error and things fail without proper error messages (I've tried
>> > to add some debug output. I caused mock build to stop dead). You can not
>> > do as many calls as you want (like you can for %doc) or rpm will
>> > complain of multiple %posts or %files for the same subpackage (without
>> > telling you exactly which subpackage fails)
>> >
>> > The choice that was made was to minimize human error risk at the expense
>> > of some prettiness in koji. I'd do the same choice today in a blink.
We
>> > are severely limited what the tools can do, but trying to accomodate
>> > tools at all costs results in undue human burden and lots of bad
>> > packages. Humans have limits too.
>>
>> Sorry, but the decision has been made, you have to put the macro where it
>> belongs. Something which expands to scriptlets and %files sections needs to
>> go where the scriptlets and %files sections belong, NOT in the Summary where
>> it will be wrong in the SRPM. The problem is that it's not only within Koji
>> that the unexpanded macros show up, but also in the shipped SRPMs!
>
> Why can't the following be used?
> %{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
In theory in can. In practice that will increase the number of human mistakes
since it is not a human-friendly syntax. Again my #1 objective is not to be
pretty but to have something that works user-side with the packagers we have.
(I'd like to have pretty srpms too but I'll settle with error-free rpms any
day)
Your priorities do not match with a good deal of the packaging community
here. #1 priority should be to produce correct packages. Making doing that
easy is likely in the running for #2, though.
In this case, we have something that affects the packages that end users see
so that takes precedence over making it easy for humans to do what is right.
We can make it as easy as possible for the right thing to be done but
actually doing the wrong thing and thinking it's okay is not.
Your argument that the SRPM is only seen by a tiny fraction of our endusers
and therefore we shouldn't worry about doing the right thing when it only
affects SRPMS is a valid question. I think SRPMs should be worried about
but you can certainly write a draft to remove or modify the buildtime SRPM
macros guideline on that basis and the full FPC will vote on it.
Anyway I've taken the time to explain why the current wording is ambiguous (I
do not use macros in summaries, that rpm fails to see where the summary ends
is no fault of mine). I've taken the time to explain my problem (I need
something which is simple enough people do not spend their time adding and
correcting bugs induced by quirky rpm syntax).
Hopefully the wording I've added at till's prompting will clarify that
your
usage is running afoul of the Guideline. Writing a draft to ask FPC to
consider SRPMs of lesser importance than binary rpms and allow this when
it makes the life of the packager easier to ignore the problem is still an
option though.
If the aim is not to find the
best compromise for everyone, but to play the 'too late, it's been decided,
just do it' game (though I respectfully point out no guideline is in effect
before FESCO approval)
This was Kevin Kofler's statement, rather than the FPC (or any FPC members).
You're welcome to bring it up and we can discuss it. However, I think this
is a case that does fall under what we want to fix by this Guideline. You
are correct that FESCo also has to approve the change and you are welcome to
petition them with your argument as well. I do think that FPC has been
delegated the authority in this area by FESCo though.
I'll play the 'compliance with 2010 guidelines is
planified after full-distro compliance with 2008 guidelines is done' game.
This part is childish. Although, if you want to use your provenpackager
status to help find and fix low hanging fruit in those other packages that
would be grat.
Some things are easy to take into account. This change is not,
because it
depends on humans not making human mistakes (not like the define=>global
change that was 100% equivalent for humans). I don't see how the induced work
could even remotely be worth it. (remember, this is only about prettifying
summaries in srpms and koji no one but a tiny part of our user base will ever
look at).
Mentioned up above that you can have the relavance of SRPMs questioned but
there's another thing in here that should be addressed. It is true that
humans make mistakes. But it is a packagers job to overcome those
difficulties and package correctly. And it's a reviewers job to catch
mistakes that a packager makes.
We definitely should try to make the Guidelines as easy to apply as possible
to avoid places where human error can occur but in the end we're responsible
for creating correct packages whether the job is easy or hard.
-Toshio
4:26 p.m.
Le jeudi 04 février 2010 à 11:16 -0500, Toshio Kuratomi a écrit :
On Thu, Feb 04, 2010 at 11:49:46AM +0100, Nicolas Mailhot wrote:
>
>
> Le Jeu 4 février 2010 10:26, Till Maas a écrit :
> > On Thu, Feb 04, 2010 at 09:20:12AM +0100, Kevin Kofler wrote:
> >> Nicolas Mailhot wrote:
> >> > That would probably avoid the koji display problem but is sure to
> >> > introduce packaging bugs. The macro call has been put in this
particular
> >> > place because experience shows that reduces human mistakes. It's
never
> >> > easy to do back and forths between two parts of the same file, but in
> >> > this case they are compounded by the kind of syntax forced on us by
the
> >> > use of a macro. Everything needs to be cramed on a single line. Any
> >> > syntax error and things fail without proper error messages (I've
tried
> >> > to add some debug output. I caused mock build to stop dead). You can
not
> >> > do as many calls as you want (like you can for %doc) or rpm will
> >> > complain of multiple %posts or %files for the same subpackage
(without
> >> > telling you exactly which subpackage fails)
> >> >
> >> > The choice that was made was to minimize human error risk at the
expense
> >> > of some prettiness in koji. I'd do the same choice today in a
blink. We
> >> > are severely limited what the tools can do, but trying to accomodate
> >> > tools at all costs results in undue human burden and lots of bad
> >> > packages. Humans have limits too.
> >>
> >> Sorry, but the decision has been made, you have to put the macro where it
> >> belongs. Something which expands to scriptlets and %files sections needs
to
> >> go where the scriptlets and %files sections belong, NOT in the Summary
where
> >> it will be wrong in the SRPM. The problem is that it's not only within
Koji
> >> that the unexpanded macros show up, but also in the shipped SRPMs!
> >
> > Why can't the following be used?
> > %{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
>
> In theory in can. In practice that will increase the number of human mistakes
> since it is not a human-friendly syntax. Again my #1 objective is not to be
> pretty but to have something that works user-side with the packagers we have.
> (I'd like to have pretty srpms too but I'll settle with error-free rpms any
> day)
>
Your priorities do not match with a good deal of the packaging community
here. #1 priority should be to produce correct packages. Making doing that
easy is likely in the running for #2, though.
In this case, we have something that affects the packages that end users see
so that takes precedence over making it easy for humans to do what is right.
We can make it as easy as possible for the right thing to be done but
actually doing the wrong thing and thinking it's okay is not.
Your argument that the SRPM is only seen by a tiny fraction of our endusers
and therefore we shouldn't worry about doing the right thing when it only
affects SRPMS is a valid question.
No, my argument is that the problem this tries to protect against is
purely cosmetic, and is cosmetic in an area which has little practical
importance. That makes it very low in my priority scale. Nevertheless I
would support the fix anyway if it was safe. But it is not safe, it's
trading a problem which has no real practical consequences, for problems
that do have practical consequences.
It's too easy to say packagers just have to do better, packager time is
not limitless, it's a precious resource people are asking to squander
just because they can here. The day I have three candidates to package
each font the design team asks for I'll support this kind of nitpicking,
but in the meanwhile this kind of "just do it, packagers have to bear
the burden of working around rpm limits at any cost, even for cosmetic
issues" is not practical at all.
I've already written where efforts could be best allocated if this
"problem" was a priority (actually fixing rpmbuild so no manual
labour-intensive workarounds are required). I seriously question it is
worth it short term even with the "fix the actual rpmbuild bug"
approach. But the manual approach is insane (if someone has this kind of
manpower available I have a long long list of packages badly needing
fixing not just for cosmetic reasons, and fonts badly needing packaging)
--
Nicolas Mailhot
7:26 p.m.
On Thu, Feb 04, 2010 at 11:26:22PM +0100, Nicolas Mailhot wrote:
No, my argument is that the problem this tries to protect against is
purely cosmetic, and is cosmetic in an area which has little practical
importance. That makes it very low in my priority scale. Nevertheless I
would support the fix anyway if it was safe. But it is not safe, it's
trading a problem which has no real practical consequences, for problems
that do have practical consequences.
If you don't like it, talk to FESCo or write something up for FPC to look
at. If you think that reviewers can't be bothered to look for places that
a package has a bug, packagers don't have time to fix bugs reported against
their packages, and you don't have enough faith that FESCo or the FPC will
find your argument that "cosmetic issues in an area which has little
practical importance" are valid, then really, there's nothing else I can do
to help.
-Toshio
2:56 a.m.
On Thu, Feb 04, 2010 at 11:26:22PM +0100, Nicolas Mailhot wrote:
No, my argument is that the problem this tries to protect against is
purely cosmetic, and is cosmetic in an area which has little practical
importance. That makes it very low in my priority scale. Nevertheless I
would support the fix anyway if it was safe. But it is not safe, it's
trading a problem which has no real practical consequences, for problems
that do have practical consequences.
It's too easy to say packagers just have to do better, packager time is
not limitless, it's a precious resource people are asking to squander
just because they can here. The day I have three candidates to package
each font the design team asks for I'll support this kind of nitpicking,
but in the meanwhile this kind of "just do it, packagers have to bear
the burden of working around rpm limits at any cost, even for cosmetic
issues" is not practical at all.
+1.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
5:08 p.m.
Toshio Kuratomi wrote:
This was Kevin Kofler's statement, rather than the FPC (or any
FPC
members). You're welcome to bring it up and we can discuss it. However, I
think this is a case that does fall under what we want to fix by this
Guideline. You are correct that FESCo also has to approve the change and
you are welcome to petition them with your argument as well. I do think
that FPC has been delegated the authority in this area by FESCo though.
I'll also note that I'm in FESCo and that I'll definitely vote for approving
this FPC guideline, as I don't see why we should block it. Valid reasons
have been given for why this is bad and Nicolas's counterarguments just boil
down to laziness.
Kevin Kofler
5:20 p.m.
I wrote:
I'll also note that I'm in FESCo and that I'll definitely
vote for
approving this FPC guideline, as I don't see why we should block it. Valid
reasons have been given for why this is bad and Nicolas's counterarguments
just boil down to laziness.
PS: This was already discussed in the 2010-01-08 FESCo meeting and we agreed
the unexpanded macros are a problem and tasked the FPC to come up with a
guideline to ban them. So I don't see why we'd block the guideline now.
Nicolas's arguments don't convince me at all.
Kevin Kofler
5:14 p.m.
Nicolas Mailhot wrote:
Le Jeu 4 février 2010 10:26, Till Maas a écrit :
> Why can't the following be used?
> %{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
In theory in can. In practice that will increase the number of human
mistakes since it is not a human-friendly syntax. Again my #1 objective is
not to be pretty but to have something that works user-side with the
packagers we have. (I'd like to have pretty srpms too but I'll settle with
error-free rpms any day)
This is ridiculous. How hard can it be to copy&paste this syntax? That said,
I think moving the macro to where it belongs (along with the other
scriptlets and file lists) is the better solution. Either way, our
guidelines should be optimized for correctness, not laziness or
incompetence.
By the way, the whole concept of this kind of macros has been frowned upon
and FESCo already recommended that the MinGW packagers simply paste their
debuginfo logic directly into the specfiles instead of using this kind of
macros. I guess the same recommendation can be given to the font packagers.
Anyway I've taken the time to explain why the current wording is
ambiguous
(I do not use macros in summaries, that rpm fails to see where the summary
ends is no fault of mine). I've taken the time to explain my problem (I
need something which is simple enough people do not spend their time
adding and correcting bugs induced by quirky rpm syntax). If the aim is
not to find the best compromise for everyone, but to play the 'too late,
it's been decided, just do it' game (though I respectfully point out no
guideline is in effect before FESCO approval) I'll play the 'compliance
with 2010 guidelines is planified after full-distro compliance with 2008
guidelines is done' game.
You don't have to enforce this, we can assign any provenpackager to do so.
For new packages, it should be part of the review checklist.
Kevin Kofler
7:25 a.m.
Le Sam 6 février 2010 00:14, Kevin Kofler a écrit :
By the way, the whole concept of this kind of macros has been frowned
upon
and FESCo already recommended that the MinGW packagers simply paste their
debuginfo logic directly into the specfiles instead of using this kind of
macros. I guess the same recommendation can be given to the font packagers.
Kevin,
I'm sorry but you are full of crap here (kindest statement I could make). If
you don't want to understand the problem space don't pontificate about it.
Look out in cvs the state our font packages were before and the state they are
now before stating it's ok to make it harder for human beings because they owe
us perfectness. Using macros is the single change that made is possible for
Fedora to scale out without sacrificing quality (the srpm summary buglet is
nothing compared to the mistakes people were doing before)
--
Nicolas Mailhot
8:36 a.m.
On Sat, Feb 06, 2010 at 12:14:22AM +0100, Kevin Kofler wrote:
By the way, the whole concept of this kind of macros has been frowned
upon
and FESCo already recommended that the MinGW packagers simply paste their
debuginfo logic directly into the specfiles instead of using this kind of
macros. I guess the same recommendation can be given to the font packagers.
Why is code duplication considered good practice here, while it is
considered to be bad practice everywhere else, e.g. in the no duplicate
system libraries guidelines?
Regards
Till
9:19 a.m.
On Thu, Feb 04, 2010 at 10:26:05AM +0100, Till Maas wrote:
On Thu, Feb 04, 2010 at 09:20:12AM +0100, Kevin Kofler wrote:
> Nicolas Mailhot wrote:
> > That would probably avoid the koji display problem but is sure to
> > introduce packaging bugs. The macro call has been put in this particular
> > place because experience shows that reduces human mistakes. It's never
> > easy to do back and forths between two parts of the same file, but in
> > this case they are compounded by the kind of syntax forced on us by the
> > use of a macro. Everything needs to be cramed on a single line. Any
> > syntax error and things fail without proper error messages (I've tried
> > to add some debug output. I caused mock build to stop dead). You can not
> > do as many calls as you want (like you can for %doc) or rpm will
> > complain of multiple %posts or %files for the same subpackage (without
> > telling you exactly which subpackage fails)
> >
> > The choice that was made was to minimize human error risk at the expense
> > of some prettiness in koji. I'd do the same choice today in a blink. We
> > are severely limited what the tools can do, but trying to accomodate
> > tools at all costs results in undue human burden and lots of bad
> > packages. Humans have limits too.
>
> Sorry, but the decision has been made, you have to put the macro where it
> belongs. Something which expands to scriptlets and %files sections needs to
> go where the scriptlets and %files sections belong, NOT in the Summary where
> it will be wrong in the SRPM. The problem is that it's not only within Koji
> that the unexpanded macros show up, but also in the shipped SRPMs!
Why can't the following be used?
%{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
That would be another option.
Since the macro is not really part of the Summary, there is no
missing
information if it does not expand.
Btw. the guidelines looks incomplete. This is the second sentence:
| Because SRPMs are built without the package's BuildRequires installed,
| depending on macros defined outside of the spec file can easily lead to
| this issue.
But there is no real explanation of "the issue", e.g. the problem that
macros that are not really intended to build the packages description
are shown unexpanded in the description.
Thanks. Added a few words about the end effect we're trying to avoid.
-Toshio
4:28 p.m.
On Wed, Feb 03, 2010 at 02:29:18PM -0500, Toshio Kuratomi wrote:
The committee started voting on new Guidelines for python modules that
includes Guidelines for python3 but suffered network difficulties in the
middle of the discussion. This will ocntinue on the packaging mailing list
and hopefully be voted on later this week.
https://fedoraproject.org/wiki/PackagingDrafts/Python3
Current state:
For: 3 rdieter, tibbs, abadger1999
Against: 1 racor racor wants to have a note in the guidelines of when the
python-2.x package will be removed from Fedora. Other committee members
argued that this was 1) out of scope for the FPC (would be a packagr or
FESCo decision) and 2) impossible to know at this juncture as the uptake
of python3 among module authors is not yet very high -- that leads to no
one being able to port because their dependencies have not been ported.
This was passed via vote on the mailing list so it has been added to the
list of Guidelines for FESCo to ratify at its next meeting.
-Toshio
2:59 a.m.
On Wed, Feb 03, 2010 at 02:29:18PM -0500, Toshio Kuratomi wrote:
SRPM Buildtime macros
https://fedoraproject.org/wiki/SRPM_Buildtime_macros
Did we consider fixing the bug in RPM/the packaging system instead of
pushing more work on packagers?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
9:13 a.m.
On Fri, Feb 05, 2010 at 08:59:52AM +0000, Richard W.M. Jones wrote:
On Wed, Feb 03, 2010 at 02:29:18PM -0500, Toshio Kuratomi wrote:
> SRPM Buildtime macros https://fedoraproject.org/wiki/SRPM_Buildtime_macros
Did we consider fixing the bug in RPM/the packaging system instead of
pushing more work on packagers?
This is not a response to a bug in rpm. This addresses people trying to put
macros into %descriptions when those macros aren't defined at the time of
build.
Nicolas's argument is that rpm does not automatically detect when he wants
to end his %description and therefore he should be excluded from the
requirement.
-Toshio
9:21 a.m.
On Fri, Feb 5, 2010 at 9:13 AM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
Nicolas's argument is that rpm does not automatically detect when
he wants
to end his %description and therefore he should be excluded from the
requirement.
Would it make sense to have %end available to terminate spec file
sections like it does in kickstarts?
9:56 a.m.
On Fri, Feb 05, 2010 at 10:13:52AM -0500, Toshio Kuratomi wrote:
On Fri, Feb 05, 2010 at 08:59:52AM +0000, Richard W.M. Jones wrote:
> On Wed, Feb 03, 2010 at 02:29:18PM -0500, Toshio Kuratomi wrote:
> > SRPM Buildtime macros https://fedoraproject.org/wiki/SRPM_Buildtime_macros
>
> Did we consider fixing the bug in RPM/the packaging system instead of
> pushing more work on packagers?
>
This is not a response to a bug in rpm. This addresses people trying to put
macros into %descriptions when those macros aren't defined at the time of
build.
Imho this is only what the guidelines say and it sounds to apply to use
cases like:
%description
This is a PyYAML for Python: %{python_version}
So the macro is part of what is going into the package's description.
Especially the case that it does not only mention %desription, but also
Summary make this very likely to be understood like this. E.g. why would
someone put a macro into the Summary tag, if not to make it appear in
the Summary tag?
Nicolas's argument is that rpm does not automatically detect when
he wants
to end his %description and therefore he should be excluded from the
requirement.
The argument is, that the macro is not used to create the %description
afaics. Imho this is a valid way, because using his macros before
%description seems not to work (I believe I tried). So for this case,
there is really a bug or annoyance in rpm: It's not possible to use
external macros at a good visible place within the SPEC that does not
end up in the %description if it is not expanded.
I also agree that fixing rpm should be at least the long goal and
that the issue should also be tracked, before there is an official
Guideline to work around this deficiency.
Regards
Till
10:49 a.m.
On 05/02/10 15:56, Till Maas wrote:
On Fri, Feb 05, 2010 at 10:13:52AM -0500, Toshio Kuratomi wrote:
> On Fri, Feb 05, 2010 at 08:59:52AM +0000, Richard W.M. Jones wrote:
>> On Wed, Feb 03, 2010 at 02:29:18PM -0500, Toshio Kuratomi wrote:
>>> SRPM Buildtime macros https://fedoraproject.org/wiki/SRPM_Buildtime_macros
>>
>> Did we consider fixing the bug in RPM/the packaging system instead of
>> pushing more work on packagers?
>>
> This is not a response to a bug in rpm. This addresses people trying to put
> macros into %descriptions when those macros aren't defined at the time of
> build.
Imho this is only what the guidelines say and it sounds to apply to use
cases like:
%description
This is a PyYAML for Python: %{python_version}
So the macro is part of what is going into the package's description.
Especially the case that it does not only mention %desription, but also
Summary make this very likely to be understood like this. E.g. why would
someone put a macro into the Summary tag, if not to make it appear in
the Summary tag?
> Nicolas's argument is that rpm does not automatically detect when he wants
> to end his %description and therefore he should be excluded from the
> requirement.
The argument is, that the macro is not used to create the %description
afaics. Imho this is a valid way, because using his macros before
%description seems not to work (I believe I tried). So for this case,
there is really a bug or annoyance in rpm: It's not possible to use
external macros at a good visible place within the SPEC that does not
end up in the %description if it is not expanded.
I also agree that fixing rpm should be at least the long goal and
that the issue should also be tracked, before there is an official
Guideline to work around this deficiency.
Wouldn't this problem be avoided if the SRPM was built in a buildroot
containing all of the buildreqs (like the binary RPMs are)?
It would be an extra step in the build process, but not a big extra step.
1. Build SRPM in minimal buildroot to determine buildreqs (as currently)
2. Populate buildroot with buildreqs (as currently)
3. Rebuild SRPM in this buildroot (this is the extra step)
4. Build binary RPMs in this buildroot (as currently)
Paul.
5:24 p.m.
Paul Howarth wrote:
Wouldn't this problem be avoided if the SRPM was built in a
buildroot
containing all of the buildreqs (like the binary RPMs are)?
It would be an extra step in the build process, but not a big extra step.
1. Build SRPM in minimal buildroot to determine buildreqs (as currently)
2. Populate buildroot with buildreqs (as currently)
3. Rebuild SRPM in this buildroot (this is the extra step)
4. Build binary RPMs in this buildroot (as currently)
This was discussed in the 2010-01-08 FESCo meeting (with people from rel-eng
also present). It was decided that this was not worth the effort and that
using macros in SRPMs in this way is not something we want to support.
Kevin Kofler
4:27 p.m.
On Sat, Feb 06, 2010 at 12:24:08AM +0100, Kevin Kofler wrote:
Paul Howarth wrote:
> Wouldn't this problem be avoided if the SRPM was built in a buildroot
> containing all of the buildreqs (like the binary RPMs are)?
>
> It would be an extra step in the build process, but not a big extra step.
>
> 1. Build SRPM in minimal buildroot to determine buildreqs (as currently)
> 2. Populate buildroot with buildreqs (as currently)
> 3. Rebuild SRPM in this buildroot (this is the extra step)
> 4. Build binary RPMs in this buildroot (as currently)
This was discussed in the 2010-01-08 FESCo meeting (with people from rel-eng
also present). It was decided that this was not worth the effort and that
using macros in SRPMs in this way is not something we want to support.
Normally automation and lack of duplication is regarded as a good
thing.
Package X and mingw32-X are related. The description of mingw32-X
could be something like:
"This package is the library X, cross-compiled for 32 bit Windows.
Do NOT install this package if you want the native library X
(install package 'X' instead).
Install this package only if you want to cross-compile a program
which uses library X."
In almost any other area of computer science one would use a macro for
this. RPM doesn't always expand macros in the %description section.
That's a bug in RPM and/or the build system.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
9:36 a.m.
On Sun, 2010-02-07 at 22:27 +0000, Richard W.M. Jones wrote:
Normally automation and lack of duplication is regarded as a good
thing.
Package X and mingw32-X are related. The description of mingw32-X
could be something like:
"This package is the library X, cross-compiled for 32 bit Windows.
Do NOT install this package if you want the native library X
(install package 'X' instead).
Install this package only if you want to cross-compile a program
which uses library X."
In almost any other area of computer science one would use a macro for
this. RPM doesn't always expand macros in the %description section.
That's a bug in RPM and/or the build system.
This is kind of a bug in the build system, but it's... debatable.
Here's the scenario. When submitting a build to koji, koji launches a
task to construct the SRPM. This task checks out the package from CVS,
downloads any additional sources from the lookaside cache, and runs
rpmbuild -bs to build the SRPM. The output of this task is the SRPM,
which is then handed to the per-arch build tasks as input.
This task runs in a chroot. This chroot is minimal, so the only
packages around to define rpm macros are redhat-rpm-config and rpm
itself. rpm, unlike other string languages like make (or even Bourne
shells) does not substitute empty strings for undefined macros. So if
an undefined macro is present in the spec file in %description, it'll be
emitted into the SRPM unexpanded. (Whether the binary RPMs emitted from
the arch build tasks expand this variable depends on whether a package
to expand the macro is installed, and whether that field is inherited
from the SRPM or expanded from the spec file; I'm almost certain it's
the latter.)
You might like to install additional packages before actually running
the rpmbuild -bs, but rpm has no way of expressing this kind of
"SourceBuildRequires". You could add it out of band in another file in
CVS, but that's unpleasant, since you'd want that metadata captured in
the SRPM and it wouldn't be unless you added a SourceNNN like for it.
So I mean, you could add it to redhat-rpm-config, but at least in this
case I don't see a huge benefit. That kind of templating seems like it
belongs in rpmdev-newspec(1).
- ajax
2:54 p.m.
On Mon, 2010-02-08 at 10:36 -0500, Adam Jackson wrote:
You might like to install additional packages before actually
running
the rpmbuild -bs, but rpm has no way of expressing this kind of
"SourceBuildRequires".
By default, rpmbuild -bs fails if BuildRequires aren't present. This
suggests that the existing expectation in RPM is that BuildRequires
*are* SourceBuildRequires.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:03 p.m.
On Mon, 2010-02-08 at 12:54 -0800, Adam Williamson wrote:
On Mon, 2010-02-08 at 10:36 -0500, Adam Jackson wrote:
> You might like to install additional packages before actually running
> the rpmbuild -bs, but rpm has no way of expressing this kind of
> "SourceBuildRequires".
By default, rpmbuild -bs fails if BuildRequires aren't present. This
suggests that the existing expectation in RPM is that BuildRequires
*are* SourceBuildRequires.
Huh. I may be wrong on that. Just tested, and it seems it doesn't now.
Either I'm misremembering, or it's old behaviour that's changed, or it's
a Fedora patch...sorry...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:16 p.m.
On Mon, 08 Feb 2010 12:54:56 -0800, Adam wrote:
On Mon, 2010-02-08 at 10:36 -0500, Adam Jackson wrote:
> You might like to install additional packages before actually running
> the rpmbuild -bs, but rpm has no way of expressing this kind of
> "SourceBuildRequires".
By default, rpmbuild -bs fails if BuildRequires aren't present.
Which is the reason, why tools like mock build the first src.rpm
with -bs --nodeps, ... but this has been changed more than a year
ago. Since then -bs implies --nodeps.
This
suggests that the existing expectation in RPM is that BuildRequires
*are* SourceBuildRequires.
Sure, but that doesn't help much if the buildsys needs to create a
src.rpm from just the spec file. Since the spec file's BuildRequires
become the src.rpm's Requires, it's a chicken-and-egg problem.
5232
days inactive
5237
days old
33 comments
11 participants
participants (11)
-
Adam Jackson -
Adam Williamson -
Garrett Holmstrom -
Jesse Keating -
Kevin Kofler -
Michael Schwendt -
Nicolas Mailhot -
Paul Howarth -
Richard W.M. Jones -
Till Maas -
Toshio Kuratomi