Strange buildconflicts

[Per Øyvind Karlsen]

When touching db* packages, I notice this odd buildconflicts:
BuildConflicts: libreoffice-core

Tomasz, care to elaborate about the necessity of this?
(It would btw. be nice if people did better at not only documenting exactly
what they've done in commit messages, but also it's rationale whenever it's
not too obvious (either in commit message or as a comment in spec file:).

--
Regards,
Per Øyvind

[Jeffrey Johnson]

BuildConflicts: libreoffice-core

While I have no idea what the semantic intent of the above is/was, I can point out

BuildObsoletes: exists/functions and is perhaps a better solution than BuildConflicts:
if the intent is to create a tree in which a package can be rebuilt. Note that the effect
is harmless when installing as non-root (which is suggested as best practice for
rpmbuild for many years now), but would permit re-running "sudo rpmbuild" and "fixing"
the problem automagically.

Note also that
BuildRequires: !libpreoffice-core
(note the leading ! for negation) is essentially the same as the BuildConflicts: used.

There is a similar symmetry relationship between BuildObsoletes: and negated BuildProvides:,
the major difference being the actual side-effect when a negated dependency is evaluated
against the complement of the installed set.

(if that statement doesn't make sense, Don't worry! Be Happy! Let's go shopping!)

hth

73 de Jeff

[Per Øyvind Karlsen]

Post by Jeffrey Johnson

BuildConflicts: libreoffice-core

While I have no idea what the semantic intent of the above is/was, I can
point out
BuildObsoletes: exists/functions and is perhaps a better solution than
if the intent is to create a tree in which a package can be rebuilt. Note
that the effect
is harmless when installing as non-root (which is suggested as best
practice for
rpmbuild for many years now), but would permit re-running "sudo rpmbuild"
and "fixing"
the problem automagically.
Note also that
BuildRequires: !libpreoffice-core
(note the leading ! for negation) is essentially the same as the
BuildConflicts: used.

Interesting, so will this then be added to %{requirenames} with some
special attribute set, or is it added to %{conflictnames}?

--
Regards,
Per Øyvind

[Jeffrey Johnson]

Interesting, so will this then be added to %{requirenames} with some special attribute set, or is it added to %{conflictnames}?

No idea what you mean by %{requirenames} since there are 7 interpretations,
all dependent on context, for the character % used in spec files.

In general, RPM provides a literal reformatting of what packagers (and configured
distro scripts) from a *.spec build recipe into header tag data.

Short answer:
I expect to see "!foo" in *.rpm header RPMTAG_REQUIRENAME tag data if/when
BuildRequires: !foo
is added in a spec file.

DIsclaimer:
I am _NOT_ responsible for how rpm.org or depsolvers interpret "!foo" in metadata.

73 de Jeff

[Per Øyvind Karlsen]

Post by Per Øyvind Karlsen

Post by Per Øyvind Karlsen
Interesting, so will this then be added to %{requirenames} with some

special attribute set, or is it added to %{conflictnames}?
No idea what you mean by %{requirenames} since there are 7 interpretations,
all dependent on context, for the character % used in spec files.

Ah, sure, I was thinking of RPMTAG_REQUIRENAME. :)

Post by Per Øyvind Karlsen
In general, RPM provides a literal reformatting of what packagers (and
configured
distro scripts) from a *.spec build recipe into header tag data.
I expect to see "!foo" in *.rpm header RPMTAG_REQUIRENAME tag data
if/when
BuildRequires: !foo
is added in a spec file.

So this is then RPMTAG_REQUIRENAME with some negative attribute (set by
RPMTAG_REQUIREFLAGS bit) or something?

--
Regards,
Per Øyvind

[Jeffrey Johnson]

Post by Jeffrey Johnson
I expect to see "!foo" in *.rpm header RPMTAG_REQUIRENAME tag data if/when
BuildRequires: !foo
is added in a spec file.
So this is then RPMTAG_REQUIRENAME with some negative attribute (set by RPMTAG_REQUIREFLAGS bit) or something?

No.

RPMTAG_REQUIREFLAGS has no changes with
Requires: !foo
because there is no comparison, only existence, involved.

Think a bit ...

73 de Jeff