FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-03-2010, 08:19 PM
Nicolas Mailhot
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-03-2010, 08:28 PM
Jesse Keating
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-03-2010, 08:55 PM
Nicolas Mailhot
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-03-2010, 09:14 PM
Toshio Kuratomi
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-03-2010, 09:28 PM
Toshio Kuratomi
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-03-2010, 09:46 PM
Nicolas Mailhot
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-03-2010, 09:48 PM
Nicolas Mailhot
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-03-2010, 10:33 PM
Toshio Kuratomi
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-04-2010, 05:53 AM
Nicolas Mailhot
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-04-2010, 07:20 AM
Kevin Kofler
 
Default Packaging Committee Meeting Summary (2010-02-03)

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

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

Thread Tools




All times are GMT. The time now is 02:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org