Re: Packaging Committee Meeting Summary (2010-02-03)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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 pgpy2X3Miql4F.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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
Re: 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
Re: Packaging Committee Meeting Summary (2010-02-03)
On Fri, Feb 05, 2010 at 08:59:52AM +, 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 pgpYoHuv8dsUR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
On Fri, Feb 5, 2010 at 9:13 AM, Toshio Kuratomi a.bad...@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
Re: 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 +, 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
Re: 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
Re: Packaging Committee Meeting Summary (2010-02-03)
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 copypaste 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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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
Re: Packaging Committee Meeting Summary (2010-02-03)
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
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
pgpr3rXhn0FsS.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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
Re: 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 pgpbYJkuBvEAR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 pgpR4Uokxyz5W.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 pgpuPUWmdgsNF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 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 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
