On Thu, 28 Nov 2013, NeilBrown wrote:
We already have krb5-mini (to avoid another cycle). If we can get rid
of libgsslglue and krb5-mini is free of further dependencies (which it
wasn't last time I tried), we can try.
Note that here also specifically build requirements are important
(in addition to install-time requirements).
Once again I have no idea what you mean. In what way, precisely, are build
requirements important. In what way might they go wrong? What must we be
careful to ensure?
The cycles that coolo talks about are build cycles. They are the results
of cycles in build dependencies. Build dependencies for package X are the
union of its BuildRequires plus the closure union over the Requires and
BuildRequires of those. Trivial example: rpm BuildRequires gcc, gcc
Requires binutils, binutils BuildRequires gcc, hence there's a
(small) cycle rpm-gcc-binutils. There are many more packages entering
that particular cycle (which basically is that gcc requires itself to
build), e.g. patch, file, expect, expat, flex, bison, cpio, perl,
util-linux, zlib, make and so on. Most of these make immediate sense,
because they are indeed necessary to create executable from C sources and
package them via rpm.
One part of that (already large) build cycle is pam, and hence all
dependencies of pam, this isn't as obvious, but there are reasons for that
(needed by coreutils). As soon as a package enters such a cycle _all_
it's dependencies enter the cycle too. So a package entering a cycle for
the first time is potentially a desaster as it can enlargen the cycle by
And it is a desaster because such cycles are handled in a special way by
the build service. As long as a package of a cycle is still building no
other package (not part of the cycle but depending on it) starts building.
And packages in a cycle build until a fixed point is reached (basically
until no package build results in a different package than the last build,
though the definition of "difference" is a bit convoluted). The result is
that packages in a cycle build potentially many times (usually at least
twice). The more packages there are in the cycle the higher the chances
that the whole thing is built more than twice. So large cycles will
tremedously increase the build times for a full rebuild of the respective
build tree containing it. Also as soon as any part of a cycle is checked
in the whole cycle needs rebuilding, also when the change is in a package
that _sounds_ like it's a leaf package.
You can see current cycles e.g. for 13.1 at
You'll see that libgssglue is in the bootstrap cycle (the one containing
gcc/rpm/binutils/glibc). Including krb5 therein will be problematic, it
will add much of the python and openldap2 stacks. E.g. checking in
python-Sphinx then would lead to a full rebuild of the bootstrap cycle,
gcc, glibc, binutils, automake/autoconf, and from there rebuilding _all_
of the distro (because the compiler rebuilt with most probably different
So, one wants to avoid adding to the bootstrap cycle even at _extremely_
large cost in maintaining e.g. several .spec files that have less
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org