Re: `BuildRecommends' proposal

[Enrico Scholz <enrico scholz informatik tu-chemnitz de>]

eli.carter@inet.com (Eli Carter) writes:

> Enrico Scholz wrote:
> [snip]
> > An issue related to the `BuildRecommends'-tag is the behavior while
> > upgrading a package. A package with all fulfilled recommendations
> > (being called full-package now) should takes precedence over older
> > packages (serial + version + release) or the same package with a
> > missing recommendation (called half-package now).
> > 
> > The critical case is the comparision of a half-package and an older
> > full-package. I think the half-package should take precedence because
> > it is being built by the user who knows his needs and can not take
> > advantage of the extra-features of the full-package.
> 
> What about upgrading a half-package to a half-package with a different
> set of fullfilled buildrequirements?

This is a difficult case where no answer can be found which satisfies
everybody. I would use the following heuristic:

- the package with the highest count of satisfied recommendations will
  take precedence. Therefore the additional variable mentioned in my
  proposal could be the (negative) count of missing recommendations.

- if the same number of recommendations are fulfilled packages are
  assumed to be equal

Most distributed RPMs should be full-packages or half-packages built
within the standard environment of the used distribution. Additional
features will be compiled in by the user; mostly by fulfilling a new
recommendation without removing another one. If he does the latter, he
is on his own and has to force an upgrade.


> Example:
> package P
>   buildrecommends0: A
>   buildrecommends1: B
>   buildrecommends2: C
> 
> Currently installed:
> P 1.2.3-4 with buildrecommends 0 + 1
> 
> rpm --upgrade of the following P's:
> P 1.2.3-4 w/ 2

older package


> P 1.2.3-4 w/ 1 + 2

"same" package (both are missing one recommendation)


> P 1.2.3-5 w/ 0

newer package; upgrade

Not comparable directly, because spec-file -5 can define other
buildrecommends. Therefore normal election takes place. This case
can be a problem with automatic upgrades; but I think a user who
compiles his own packages can turn off the automatic upgrade of
such packages. People distributing (half-)packages should take care
not to release newer versions with lesser features, but this is a
general problem...


> P 1.2.3-5 w/ 0 + 2

newer package; upgrade


> Suppose P 1.2.3-6 adds "buildrecommends3: D"
> P 1.2.3-6 w/ 3

newer package; upgrade

The new `buildrecommends3' is meaningless; because release changed,
decision happens there.



> Can the same thing be accomplished by having buildrequires that
> apply to a specific sub-package?

Can it be specified to omit a sub-package to build? If not it won't take
any difference if the `BuildRecommends:' is in the main-package or in
the subpackage; the warning appears in any case.


> (With the ability to build specific sub-packages only, if that
> functionality is not already available...)

When using the %{BUILDRECOMMEND<nr>} extension, you could write:

------ foo.spec ------
BuildRecommend0: xemacs
BuildRecommend1: emacs

...
%if %{BUILDRECOMMEND0}
%package xemacs
...

%file xemacs
...
%endif

%if %{BUILDRECOMMEND1}
%package emacs
...

%file emacs
...
%endif
--------

Therefore you get foo-xemacs with installed xemacs, foo-emacs with
installed emacs, foo-emacs and foo-xemacs with installed xemacs and
emacs or nothing else.


> With 3 buildrecommends, that would translate into 8 mutually
> exclusive subpackages (and hence that many different variations
> of the name...ewww). (2^nth I'm afraid...)

I don't know exactly how powerful the %if statement in RPM is, but you
can use the shell:

| %define COND0  %(test %{BUILDRECOMMEND0} = 0 -a %{BUILDRECOMMEND0} = 0 && echo 1 || echo 0)
| %define COND1  %(test %{BUILDRECOMMEND0} = 0 -a %{BUILDRECOMMEND0} = 1 && echo 1 || echo 0)
| %define COND2  %(test %{BUILDRECOMMEND0} = 1 -a %{BUILDRECOMMEND0} = 0 && echo 1 || echo 0)
| %define COND3  %(test %{BUILDRECOMMEND0} = 1 -a %{BUILDRECOMMEND0} = 1 && echo 1 || echo 0)

These %{COND.} are mutually exclusive so you can apply them on the
subpackages as shown above. (Extending the example above to 3
buildrecommends should be trivial; but 10 or more could be become a
problem ;) )




Thanks
Enrico