Hi, On Thu, 28 Nov 2013, NeilBrown wrote:
Does that sound OK?
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).
Richard.
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 many packages. 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 https://build.opensuse.org/project/repository_state/openSUSE:13.1/standard 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 resulting rpm). 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 dependencies. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org