Ruediger Meier wrote:
On Friday 30 January 2015, Stanislav Brabec wrote:
Couldn't we just build "util-linux-light" without python and systemd and later when we have them the real "util-linux" ... and just don't let the real one trigger any rebuild?
Yes, I have been thinking about it as well, because many other projects successfully used it. It could be potentially a bit easier. But it also has its own problems. Light packages are a bit dangerous: configure script of other packages can check, whether the package supports particular feature. If not, the build would be feature-stripped. Most packages used the light version for a limited number of packages. If would not be a case of util-linux. The light package would have be a part of the base system. First victim of the light build approach was the util-linux itselt: libuuid (stage 1, "core" library), checks, whether util-linux build uuidd (stage 2 build, with systemd). Stage 1 does not include uuidd, so libuuid was feature stripped.
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.
Nevertheless we had already accepted submit request lately where these 3 specfiles were not in sync. No reviewer will carefully check whether all these triplicated changes are correct. That's why I don't like this kind of approach.
I know. But now it could be fixed by calling of pre_checkin.sh.
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.
Yep replacing all these sed lines by 3 ifdef'ed patches would do things a bit more readable again and on update we would see conflicts rather than trusting sed which never complains.
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.
I decided to use sed because it always replaced 100% of ocurrences. If a new binary appears, patch will also apply old patch without complaining, but the result would be broken. But I agree, it is ugly.
There is another issue.
If you never build everything together then you will never run the full test suite. For example currently no python test is running. So we need a 4th specfile util-linux-testsuite ...? It wouldn't make it much better because the binaries of the final rpms would remain never tested. And the fact that we build all these rpm with different patches does not make things better.
I wrote the the sed magic carefully taking testsuite in account. It seems to work for util-linux-systemd, but not for python-libmount. Please open a bug and assign it to me. The sum of test runs of all three stages should be equal to the number of tests in the all-in-one build (which does not sed magic).
The only save and also the most simple way would be to build util-linux altogether. Splits will make any packages more unsave regardless how good and hard we try to maintain it. The build loop problem is a minor problem which should be solved somehow else.
The option to build everything together still exists. And yes, building everything altogether is the safe way. But it is not acceptable for the Build Service maintainers. -- 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