I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
I happen to think Requires(hint): is a horrible syntax, because cognation with Requires(pre, post, preun, etc.): implies that some %hint scriptlet will be run at some point, but that's neither here nor there and I suspect that any upstream brain-damage is already a fait accompli.
However, there's still the question of what to do with Requires(hint): in Fedora packages. Either we get rid of it or we need to document what it does and what it might do in the future.
Strawman proposal: ban use of Requires(hint) in Fedora packages.
Comments? Votes from FPC folks?
- J<
On Sat, Jun 21, 2008 at 06:05:34PM -0500, Jason L Tibbitts III wrote:
I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
This looks like a bug. Shouldn't a 'hint' not be installed in the defaut case?
-- Pat
"PD" == Patrice Dumas pertusus@free.fr writes:
PD> This looks like a bug. Shouldn't a 'hint' not be installed in the PD> defaut case?
I think the bug is that the build proceeds at all with Requires(hint) present. I'm not sure it's handled any differently than Requires(randomcrap):. In fact, testing shows that it isn't.
The point is that our rpm doesn't seem to recognize Requires(hint) specifically. It might start doing so in the future; I don't know. If it does, I expect that the behavior will change because the current behavior isn't what you would expect if rpm actually recognized the string in parentheses. Thus I think it's a bad idea for us to have it anywhere in the distro currently.
- J<
On Sat, Jun 21, 2008 at 4:05 PM, Jason L Tibbitts III tibbs@math.uh.edu wrote:
Strawman proposal: ban use of Requires(hint) in Fedora packages.
Shouldn't this be: ban use of Requires(RandomCrapWhichIsntSupportedYet) Otherwise, I can just change my Requires(hint) to Requires(opt) or some other random crap.
"CS" == Christopher Stone chris.stone@gmail.com writes:
CS> Shouldn't this be: ban use of CS> Requires(RandomCrapWhichIsntSupportedYet) Otherwise, I can just CS> change my Requires(hint) to Requires(opt) or some other random CS> crap.
It would be disappointing to have to go to this level of lawyering. I mean, who would actually do that?
Of course, I'd hoped that people wouldn't want to use things like Requires(hint): until they're actually defined and supported, but that seems to have been a lost cause.
- J<
Jason L Tibbitts III tibbs@math.uh.edu writes:
"CS" == Christopher Stone chris.stone@gmail.com writes: CS> Shouldn't this be: ban use of CS> Requires(RandomCrapWhichIsntSupportedYet) Otherwise, I can just CS> change my Requires(hint) to Requires(opt) or some other random CS> crap.
It would be disappointing to have to go to this level of lawyering. I mean, who would actually do that?
*Everyone* is only one typo away from invoking Requires(randomcrap). ISTM this is not a policy problem. The correct response to this is to fix our tools so that you get an error if the parenthesized string isn't one of the accepted values.
If the tools enforce a list-of-accepted-values that's a bit stricter than upstream's, that's fine too; but what the heck are we doing allowing obvious mistakes in specfiles to pass?
regards, tom lane
"TL" == Tom Lane tgl@redhat.com writes:
TL> The correct response to this is to fix our tools so that you get TL> an error if the parenthesized string isn't one of the accepted TL> values.
I don't disagree, but "correct" and "workable" are different things; as much as we wish it were so, we have to work with the rpm we have, not the one we wish we had. It's certainly worth trying to get rpm changed, but this committee has in the past not had a whole lot of luck with that, and so we write guidelines which take into account rpm's issues.
- J,
Jason L Tibbitts III tibbs@math.uh.edu writes:
I don't disagree, but "correct" and "workable" are different things; as much as we wish it were so, we have to work with the rpm we have, not the one we wish we had.
Hmm, I understand that upstream might be less than tractable, but surely that doesn't prevent us from carrying our own patches that enforce restrictions that Fedora deems desirable.
I don't like carrying distro-private patches more than anyone else; but when you're talking about fundamental bits of distro infrastructure, allowing someone else to dictate our project policy doesn't seem right.
regards, tom lane
"TL" == Tom Lane tgl@redhat.com writes:
TL> Hmm, I understand that upstream might be less than tractable, but TL> surely that doesn't prevent us from carrying our own patches that TL> enforce restrictions that Fedora deems desirable.
Well, personally I don't invest a lot of time in the idea that rpm will suddenly grow sanity; I concentrate on packaging issues and how they relate to the rpm we actually have. Besides, the packaging guidelines currently cover releases that will almost certainly not receive any version of rpm that is updated to fix this issue, so its still a reasonable thing for the packaging committee to discuss.
TL> I don't like carrying distro-private patches more than anyone TL> else; but when you're talking about fundamental bits of distro TL> infrastructure, allowing someone else to dictate our project TL> policy doesn't seem right.
You seem to assume that the Fedora rpm developers will agree with you and decide to change rpm; that is certainly not a given. I would, however, encourage you to pursue that line of inquiry.
Getting a check for this kind of thing into rpmlint would be an expedient stopgap measure, but without the packaging committee actually writing a guideline, rpmlint complaints don't carry all that much weight.
- J<
Jason L Tibbitts III tibbs@math.uh.edu writes:
[ some other discussion ]
You seem to assume that the Fedora rpm developers will agree with you and decide to change rpm; that is certainly not a given.
Hm ... so this committee takes it as a given that the maintainer of RPM can arbitrarily reject any committee decision.
That's completely fine with me, because transitive closure implies that I can ignore the committee's decisions for my own packages. I think I will unsubscribe now. Call me when you've grown some backbone.
regards, tom lane
On Sun, 2008-06-22 at 02:10 -0400, Tom Lane wrote:
Hm ... so this committee takes it as a given that the maintainer of RPM can arbitrarily reject any committee decision.
Tom,
I think you're misunderstanding our "lack of backbone" here. In the recent past, we've generated patches for RPM to fix "obvious bugs", submitted them upstream, and had them rejected without alternative suggestions (aside from flame wars). In many cases, our "obvious bugs" are described by upstream as features.
The Fedora RPM maintainers (who are actually RPM's upstream as well) don't want to carry these patches either, taking an "upstream or nothing" approach to this.
In addition, when we've suggested fixes to RPM, we've gotten the feedback of "is it in the Packaging Guidelines"? Accordingly, we've adopted the strategy that:
1. It is not in the Packaging Committee's mandate (or ability) to be able to force patches into RPM. 2. The next best thing is to make guidelines which describe how RPM should/must be used in Fedora. 3. When applicable, the Packaging Committee will make suggestions based around our guidelines to RPM upstream in the hopes that our guidelines will be made obsolete.
For example, it is only now that RPM is working on setting a default BuildRoot, something we set guidelines for over a year ago.
~spot
On Sun, 22 Jun 2008, Tom \spot\ Callaway wrote:
On Sun, 2008-06-22 at 02:10 -0400, Tom Lane wrote:
Hm ... so this committee takes it as a given that the maintainer of RPM can arbitrarily reject any committee decision.
Tom,
I think you're misunderstanding our "lack of backbone" here. In the recent past, we've generated patches for RPM to fix "obvious bugs", submitted them upstream, and had them rejected without alternative suggestions (aside from flame wars). In many cases, our "obvious bugs" are described by upstream as features.
In the recent past, hmm? Care to refresh my memory, I don't remember rejecting patches for "obvious bugs"?
The Fedora RPM maintainers (who are actually RPM's upstream as well) don't want to carry these patches either, taking an "upstream or nothing" approach to this.
Well, that's one of the big principles in Fedora, isn't it? :)
In addition, when we've suggested fixes to RPM, we've gotten the feedback of "is it in the Packaging Guidelines"?
There seems to be a serious disconnect here, something being in Fedora packaging guidelines sure as hell isn't a prerequisite for getting patches accepted to rpm.org upstream. And I certainly don't recall asking for such a thing, if some response I've given has given you that impression then please point it out and lets straighten up the apparent miscommunication.
Accordingly, we've adopted the strategy that:
- It is not in the Packaging Committee's mandate (or ability) to be
able to force patches into RPM. 2. The next best thing is to make guidelines which describe how RPM should/must be used in Fedora. 3. When applicable, the Packaging Committee will make suggestions based around our guidelines to RPM upstream in the hopes that our guidelines will be made obsolete.
For example, it is only now that RPM is working on setting a default BuildRoot, something we set guidelines for over a year ago.
Yes, catching up years of abandon doesn't happen overnight...
As for Requires(randomcrap), sure it's a bug that RPM doesn't catch the error and bail out, and "hint" is just random crap as far as RPM is concerned.
Now, of course the same could be said about putting versions into changelog "author field" - it's just an ancient bug in RPM it doesn't catch "trailing garbage after email address", it just happens to be so widely abused (and even encouraged in various packaging standards) that just making the spec parser treat it as an error is not really an option.
...if you catch my drift...
I'm all for making the spec syntax stricter and saner, but things are not always so black and white. Knowingly putting invalid things into specs just because rpm doesn't currently happen to trip on them certainly does not help the cause, see above wrt the version-in-changelog thing.
- Panu -
On Sun, 2008-06-22 at 14:46 +0300, Ville Skyttä wrote:
On Sunday 22 June 2008, Jason L Tibbitts III wrote:
Strawman proposal: ban use of Requires(hint) in Fedora packages.
-1
How about a little meat to that "-1", like what you don't agree to in the proposal, alternative proposals to resolve the problem, etc...
On Sunday 22 June 2008, Jesse Keating wrote:
On Sun, 2008-06-22 at 14:46 +0300, Ville Skyttä wrote:
On Sunday 22 June 2008, Jason L Tibbitts III wrote:
Strawman proposal: ban use of Requires(hint) in Fedora packages.
-1
How about a little meat to that "-1", like what you don't agree to in the proposal, alternative proposals to resolve the problem, etc...
There's not much to say except the obvious: I just fail to see the problem you're referring to and thus see no reason why it should be banned.
The semantics (both current and future) should be pretty clear and I'd be surprised if we wouldn't eventually see tools that support it better than just treating it as equivalent to plain Requires.
I do think that Enhances:/Recommends:/Suggests: are better syntaxes than Requires(hint): though, but unlike (hint) they're not backwards compatible.
"VS" == Ville Skyttä ville.skytta@iki.fi writes:
VS> The semantics (both current and future) should be pretty clear and VS> I'd be surprised if we wouldn't eventually see tools that support VS> it better than just treating it as equivalent to plain Requires.
That's precisely my point, though. It has no use in current packages, and may change behavior according to the whims of rpm's maintainers. Not a terribly good thing to allow.
Besides, ignoring rpm's behavior for a bit, it's still a valid question as to whether this is desired in Fedora. That question touches on things like how yum and kickstart should handle such dependencies. I don't think it should be allowed until the larger questions are answered.
- J<
Jason L Tibbitts III wrote:
I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
I happen to think Requires(hint): is a horrible syntax, because cognation with Requires(pre, post, preun, etc.): implies that some %hint scriptlet will be run at some point, but that's neither here nor there and I suspect that any upstream brain-damage is already a fait accompli.
However, there's still the question of what to do with Requires(hint): in Fedora packages. Either we get rid of it or we need to document what it does and what it might do in the future.
Strawman proposal: ban use of Requires(hint) in Fedora packages.
-1 to ban, this is (potential) rpm functionality at issue here, which should *first* be discussed with rpm maintainers before any action or policy be considered.
-- Rex
Jason L Tibbitts III a écrit :
I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
Using this have one usefull purpose : documentation.
Ok, we can also use
# Optional dependency Requires: foo
My 0.02 €
Regards
On Mon, 23 Jun 2008, Remi Collet wrote:
Jason L Tibbitts III a écrit :
I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
Using this have one usefull purpose : documentation.
Abusing bugs in software for documentation purposes? Lets not...
Ok, we can also use
# Optional dependency Requires: foo
Yes, that's what comments are for.
- Panu -
On Wed, Jun 25, 2008 at 1:02 AM, Panu Matilainen pmatilai@laiskiainen.org wrote:
On Mon, 23 Jun 2008, Remi Collet wrote:
Jason L Tibbitts III a écrit :
I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
Using this have one usefull purpose : documentation.
Abusing bugs in software for documentation purposes? Lets not...
It works well for me, so I will continue to "abuse" the "bug" for documentation purposes.
My personal opinion is that this thread is making a big deal out of nothing.
On Wed, 2008-06-25 at 04:50 -0700, Christopher Stone wrote:
On Wed, Jun 25, 2008 at 1:02 AM, Panu Matilainen pmatilai@laiskiainen.org wrote:
On Mon, 23 Jun 2008, Remi Collet wrote:
Jason L Tibbitts III a écrit :
I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
Using this have one usefull purpose : documentation.
Abusing bugs in software for documentation purposes? Lets not...
It works well for me, so I will continue to "abuse" the "bug" for documentation purposes.
My personal opinion is that this thread is making a big deal out of nothing.
Provided what you say: +1 to Tibbs' initial proposal on banning Requires(hint)
Rationale: It's undocumented, error-prone pollution to spec files, which is likely to show harmful effects once rpm/yum/apt etc. should start support it.
Ralf
On Wed, Jun 25, 2008 at 5:02 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Wed, 2008-06-25 at 04:50 -0700, Christopher Stone wrote:
On Wed, Jun 25, 2008 at 1:02 AM, Panu Matilainen pmatilai@laiskiainen.org wrote:
On Mon, 23 Jun 2008, Remi Collet wrote:
Jason L Tibbitts III a écrit :
I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:.
Using this have one usefull purpose : documentation.
Abusing bugs in software for documentation purposes? Lets not...
It works well for me, so I will continue to "abuse" the "bug" for documentation purposes.
My personal opinion is that this thread is making a big deal out of nothing.
Provided what you say: +1 to Tibbs' initial proposal on banning Requires(hint)
Rationale: It's undocumented, error-prone pollution to spec files, which is likely to show harmful effects once rpm/yum/apt etc. should start support it.
If rpm/yum/apt ever started to support it, then that would be the greatest thing ever. Too bad that wont ever happen.
On Wed, 2008-06-25 at 07:13 -0700, Christopher Stone wrote:
On Wed, Jun 25, 2008 at 5:02 AM, Ralf Corsepius rc040203@freenet.de wrote:
Rationale: It's undocumented, error-prone pollution to spec files, which is likely to show harmful effects once rpm/yum/apt etc. should start support it.
If rpm/yum/apt ever started to support it, then that would be the greatest thing ever.
Well, it would be a random accident if your constructs would match with rpm's "then syntax".
E.g. openSUSE's rpm has such constructs, but they are using a different *spec-syntax. They have "Recommends:, Supplements:, Enhances:, Suggests:", not Requires(hint).
Too bad that wont ever happen.
You can never be sure. openSUSE claims to be supporting them.
Whether these are useful is a different matter.
Ralf
Ralf Corsepius rc040203@freenet.de writes:
E.g. openSUSE's rpm has such constructs, but they are using a different *spec-syntax. They have "Recommends:, Supplements:, Enhances:, Suggests:", not Requires(hint).
'Suggests:' + 'Recommends:' are synonyms for 'Requires(hint)' in upstream rpm (which creates corresponding RPMTAG_SUGGESTS* tags for them).
Enrico
On Wed, 25 Jun 2008, Enrico Scholz wrote:
Ralf Corsepius rc040203@freenet.de writes:
E.g. openSUSE's rpm has such constructs, but they are using a different *spec-syntax. They have "Recommends:, Supplements:, Enhances:, Suggests:", not Requires(hint).
'Suggests:' + 'Recommends:' are synonyms for 'Requires(hint)' in upstream rpm (which creates corresponding RPMTAG_SUGGESTS* tags for them).
Requires(hint) is only synonym for Requires(randomjunk) for rpm.org which is the upstream rpm for Fedora.
- Panu -
packaging@lists.fedoraproject.org