On Sun, 04 Jul 2010 13:22:16 +0200, Till wrote: > On Sun, Jul 04, 2010 at 12:06:39PM +0200, Michael Schwendt wrote: > > > And there would be drawbacks, too, for a hardcoded "Req => BR" rule. > > It would make circular deps impossible: Pkg A requires Pkg A-extras, > > and Pkg A-extras BR Pkg A. It would make bootstrapping a dist more > > complicated. > > For this example Pkg A-extras already BRs itself, how will the Req => BR > rule make it worse? You can build Pkg A without having Pkg A-extras in the buildroot. If, on the contrary, Pkg A had an automatic BR Pkg A-extras because it required Pkg A-extras at run-time, you could not build Pkg A (and you could not build Pkg A-extras because it BR Pkg A). > > For some pkgs (e.g. leaf pkgs) it is fine if they are > > not available in the buildroot when building a pkg that requires the > > leaf pkg at run-time. > > If a package is required at run-time, it is not a leaf package, because > a leaf package is a package that is not required by something else. Dunno what the terminology is here. A leaf node is part of a dependency tree (an end-point in a graph == a vertex with degree 1). Anything completely optional is part of its own dependency graph, which then would be a tree with one root node, which in turn would also be a leaf. :-) Example: A fonts package. And an App that requires the fonts package with an explicit Requires. If the fonts package became a BR, you could not build the App prior to the fonts package. Could be a hindrance/annoyance. > > For other pkgs it is fine if you build them > > with an old build tool for a target env that is build upon a newer tool. > > But this has nothing to do with ensuring the run-time deps are available > at build time. Off course then the BRs are not really required then, but > this is what all this is about. It is related, because the build framework (imagine it is written in Python) may be completely separate from what the built app will need at run-time. One cannot mandate that the run-time deps must be available at build-time, since then the package could only be built _after_ other packages, while theoretically it would be fine to build it independently. > But in case this rule makes it impossible to build certain packages, > than there obviously needs to be a way to disable this rule, but it can > still be default if it usually is considered to be a benefit. Well, I see a benefit in many scenarios. Req => BR mapping would also have prevented bad builds for Fedora and EPEL, which simply could not be used at all because of missing run-time dependencies. Of course, one can let packagers build crap and rely on rel-eng to verify whether the builds "fit into the target dist" with an ordinary depcheck. But packagers who verify their run-time deps when preparing a build, are aided by BR and additional guards in %prep/%check. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
