Ruediger Meier wrote:
IMO our util-linux package is completely messed up.
I agree.
Last year I had spend a lot of time to simplify it, to bring patches upstram etc. But some weeks later after update to 2.25 was finished it became even worse than before. Somehow it was required to split the package into 3 packages to prevent build loops (python, systemd deps)...
This split made the spec file unreadable und IMO unmaintainable. Just have a look how the configure.ac and Makefiles are raped in 3 different ways by dozens of nested, ifdef'ed sed lines.
Is there really no other way to solve these build loops?
No, there is no other way to solve build loops than splitting the package to three parts. python is a relatively high level package with thousands of dependencies. Also systemd has lot dependencies. The three stage build shortens bootstrap time by more than one day and saves more than 2000 of rebuild triggers. I wanted to stay with one spec with three different defines. util-linux has a high frequency of changes, and parallel manual maintenance of three nearly identical spec files would early end with diverging spec files and unapplied fixes. The task looked simple at the first look: Just add three defines, and three sets of configure options and three partially different spec preambles. So I started with that approach, and started to fail for many days. Finally I won the game, and the readability of the spec file was a cost of this Pyrrhic victory. 1) configure options of util-linux are not sufficient for such split. I deliberately went in the more complicated way: changing of source files instead of deleting of build results: - When done correctly, it should prevent undiscovered dependencies (well, I failed anyway, and one of the first subsequent bugs were about uuidd feature strip). - Changes could be upstream-able. After a discussuion with the upstream, upstream rejected the idea of staging configure options. http://www.spinics.net/lists/util-linux-ng/msg10028.html But the discussion got a consensus: Upstream will accept changes, where combinations previously invalid will turn to use of external library. So for example: "--disable-libmount --enable-python" is now an invalid combination. After changes it would be a valid combination and it will require external libmount. I don't have these patches yet. But output of the ugly scripts could be a good start point. When it will be done, the mose dangerous ugliness of the spec file will disappear, and will be replaced by three sets of configure options. 2) Yet another level of spec complexity was added by the spec auto-editing build scripts. The approach requires to fill preamble with three different sets of tags depending on part of the set actually built. (And support for build of all-in-one adds some additional lines.) I discovered that the scripts that were existing in that time were breaking my spec file. https://bugzilla.novell.com/show_bug.cgi?id=891152 The resulting black tag magic was created by Ruediger Oertel. Tags are still broken, so "osc ci --noscripts" is recommended, but the level of breakage is acceptable. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org