Le 2018-08-28 15:27, Adam Jackson a écrit :
On Tue, 2018-08-28 at 13:47 +0200, Nicolas Mailhot wrote:
Le 2018-08-07 17:33, Adam Jackson a écrit :
> Consider a library like libGL. At runtime, you want the drivers it
> might load to be installed. But when building an application, you just
> need the library itself. If the drivers themselves have non-trivial
> dependencies, the buildroot is more likely to fail to compose.
That's a boostraping problem. The general solution is to make our
build
tools bootstrap aware, so they activate bootstrap mode as needed
automatically, instead of forcing packagers to switch the conditional
manually in spec files each time a bootstraping situation arises.
If you consider buildroot size to be a metric to be reduced - and
clearly people do, see BuildRequires: gcc - then this is not just a
bootstrapping issue.
Sure. However I suspect your solution would work fine at first and then
quickly degenerate in tricky situations as soon as the two packages
which are supposed to provide the same files lose sync (especially if
several elements in the build compose use your pattern).
Losing sync can be just: full version can not install due to broken
deps, so your builds work with the reduced version, and is then used on
user systems with previous full versions, as the new one does not
install. Of course you could add a version-lock between full and reduced
version, so your build refuses to install if there is not an exact
match, but then you have poisoned the repo with a package that built,
but is not instalable.
Is there a proposal anywhere for the kind of bootstrap awareness you
describe?
It was described about a month ago as part of the discussion on mass
rebuild tools.
Basically, if building a set of packages does not succeed, and part of
the failing packages have bootstraping logic, the build tool should try
to rebuild those in reduced mode automatically, use the result to finish
all the other builds, and then rebuild everything that was build in
reduced mode in full mode. At every step in the process there is only
one package that provides the same dep.
Regards,
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
