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-04-2010, 03:16 PM
Toshio Kuratomi
 
Default Packaging Committee Meeting Summary (2010-02-03)

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

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

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-05-2010, 07:56 AM
"Richard W.M. Jones"
 
Default Packaging Committee Meeting Summary (2010-02-03)

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-05-2010, 07:59 AM
"Richard W.M. Jones"
 
Default Packaging Committee Meeting Summary (2010-02-03)

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

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

On Fri, Feb 5, 2010 at 9:13 AM, Toshio Kuratomi <a.badger@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?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-05-2010, 02:56 PM
Till Maas
 
Default Packaging Committee Meeting Summary (2010-02-03)

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

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

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

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

Thread Tools




All times are GMT. The time now is 03:28 AM.

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