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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

>>>>> "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,

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

>>>>> "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<

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Sunday 22 June 2008, Jason L Tibbitts III wrote:

> Strawman proposal: ban use of Requires(hint) in Fedora packages.

-1

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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...

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

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.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

>>>>> "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<

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging