On Thursday 29 January 2015, Tomáš Chvátal wrote:

Dne Čt 29. ledna 2015 11:48:42, Ruediger Meier napsal(a):

...

Hi,

IMO our util-linux package is completely messed up. 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?

Sadly this really is the easiest approach,

The other solution is individual spec for each subackage that needs to be updated in sync.

I don't want another way of such unmaintable split. Just one package, preventing build loops otherwise.

Best solution would be to convince upstream to stop keeping it together and release other small subpackages.

Hm, that other packages depend on an init system (systemd) is unfortunately something very common nowadays and even wanted by openSUSE. If OBS is not able to handle it than it should probably be fixed in OBS. util-linux can still be built without systemd that's enough from upstream side. For the --with-systemd case I guess more and more ul binaries will use it in future. So our aproach to split off all sytemd stuff is doomed. [1] Also python dep is not that unusual. If util-linux would have a python based build system then we were not able to build it on OBS at all? Can't believe it. Couldn't we just build one full util-linux package again and don't let it trigger rebuilds of other packages? [1] BTW once I've tried hard to prevent adding systemd services (fstrim.service) http://comments.gmane.org/gmane.linux.utilities.util-linux-ng/8745 ... no chance ... and now look at our spec file ... what a mess for such a minor thing: $ grep fstrim util-linux.spec Provides: util-linux:/usr/lib/systemd/system/fstrim.service Provides: util-linux:/usr/lib/systemd/system/fstrim.service # for fstrim.service and fstrim.timer # trick: we do not want to build fstrim, but we want to install fstrim systemd connectors ln -s %{_sbindir}/fstrim %{buildroot}/sbin ln -sf /sbin/service %{buildroot}/usr/sbin/rcfstrim # Note: This is not a perfect solution: fstrim is part of util-linux, fstrim services are part of util-linux-systemd (for build loop prevention reasons). # If only util-linux is updated, restart of fstrim service does not happen. # Maybe we should move fstrim to util-linux-systemd in the next version. %{service_add_pre fstrim.service fstrim.timer} %{service_add_post fstrim.service fstrim.timer} %{service_del_preun fstrim.service fstrim.timer} %{service_del_postun fstrim.service fstrim.timer} /sbin/fstrim %{_sbindir}/fstrim %{_mandir}/man8/fstrim.8.gz %{_sbindir}/rcfstrim %{_unitdir}/fstrim.service %{_unitdir}/fstrim.timer cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 29 January 2015, Lars Müller wrote:

On Thu, Jan 29, 2015 at 12:49:05PM +0100, Ruediger Meier wrote:

...

On Thursday 29 January 2015, Tomáš Chvátal wrote:

...

Dne Čt 29. ledna 2015 11:48:42, Ruediger Meier napsal(a):

...

Hi,

IMO our util-linux package is completely messed up. 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?

Sadly this really is the easiest approach,

The other solution is individual spec for each subackage that needs to be updated in sync.

I don't want another way of such unmaintable split. Just one package, preventing build loops otherwise.

You might have a look at the openldap2 package. IIRC based on one spec file one or two additional are created at built time. Maybe this approach is feasible for util-linux too.

This is exactly what we do in util-linux now though util-linux.spec looks even more ugly. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

Dne 30.1.2015 v 20:13 L.A. Walsh napsal(a):

Ruediger Meier wrote:

...

Is there really no other way to solve these build loops?

---

There is a well established way to solve them.

Bootstrapping.

You build an intermediate build from an official repo of the last generation -- if it can be build with the last official "published altogether" repo (w/o any patches), that would be the best.

That builds your new generation of build tools for some "period" of time, only introducing non-interdependent products at any new build -- then test the *** out of those. It wouldn't have to be a complete test of the whole distro, but some "core" set that is needed to rebuild the distro each time.

Those cores become official build tools that are archived with *their* build tools and their sources from the previous generation.

Bootstrapping all-in-one with previous generation goes against the spirit of the openSUSE Build Service. When any single bit is changed in the package, OBS triggers to rebuild all packages that have that just-rebuilt package as build dependency. Even distributions using the bootstrap image may require three rebuilds or so to get core into a consistent state. OBS prevents superfluous rebuilds. If the package is not changed after the rebuild, no rebuild triggers are activated. But in case of util-linux, build trigger apparently were activated several times. util-linux is a bit heterogeneous set of utilities. Some of them are part of main core, others have high level of dependencies. Such core would contain e. g. python-libmount, which is invalidated by python version upgrade. But python rebuild requires tk (i. e. Xorg), just because python is another large heterogenous package. So now you have to decide: - Include Xorg and tk to the core. - Split util-linux or python build to multiple stages. - Use several thousands more rebuilds to get core into a surely consistent state. - Don't do anything of above and live with a risk of breakage.

Should it really take more than 1 BR disk / core + 2 backups for safety?

I mean this is what you would do if you didn't want to operate building skyscrapers on shifting sands all the time.

Could be a reason to justify supporting compatible and or co-existing core tools for longer periods of time rather than dropping something one cycle, only to sub in something else next. But it would take some planning a dedication to keeping a plan -- and not allowing many (if any) exceptions.

If you upgrade python, python-libmount (part of util-linux) becomes invalid. If you upgrade systemd, then uuidd, lslogins and logger may need to be recompiled. If you upgrade util-linux, it is safer to say that the whole core becomes outdated.

At least this was the way product release was handled back before the era of the 'continuous/rolling Beta'....

This was done always in SUSE. Now it is just more visible.

Seems like some sort of spreadsheet tool could be ideal for this type of job...

In case of util-linux, there are large dependency cycles with about 2000 packages on the round. The OBS paradigm "better safe than fast" brings some problems, some discovers as early as possible and prevents another. I remember problem of constant libraries breakage in early days of Gentoo caused by a complete lack of rebuild triggering.

Aren't you basically lamenting the fact that the tools are released in constant 'partially done' states that are not always consistent at anyone time?

OBS has a status "Done".

If that works -- great, but it's alot more effort, but managing a 'core-set' like a git/cvs-checkin that is tagged to represent 1 product is a bit of a chore, but I'd expect that most products, at least still do that on a product-by-product basis...no?

-- 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

Ruediger Meier wrote:

On Friday 30 January 2015, Stanislav Brabec wrote:

...

Bootstrapping all-in-one with previous generation goes against the spirit of the openSUSE Build Service. When any single bit is changed in the package, OBS triggers to rebuild all packages that have that just-rebuilt package as build dependency.

But in util-linux you do exactly the opposite now. You build systemd and python stuff against the locally built binaries which you just don't install then.

Yep.

You betray yourself. Moreover you don't even use "make install".

Yep. So maybe we are missing re-linking or ignore upstreams idea

of permissions etc. The test suite will always run incomplete and not with the binaries we have installed at the end.

Yep.

Even worse all three split subpackages are using different patches and different configure options... So neither the installed binaries nor the installed sources match together.

Actually these kind of package split violates this "spirit of the openSUSE" and also upstreams's ideas about how should it be done.

---- Well, depends on who you talk to -- but the idea of only installing the specific versions of the specific packages required for EACH package that is built has been a bugaboo I've thought was trouble for at least the past 3 years. I.e. I had this crazy idea that I should be able to take a "released version (12.1, 12,3, 13,1) (how many one includes is a semi arbitrary policy but should be at least '2 versions back), install all of the "devel" packages for that release giving a 'frozen build release' that can be used to build all of "13.2". It may be necessary to re-install (or roll back changes made during a build), the 'frozen' release, but having everything build from 1 constant base (not one that is deleted each time, and rebuilt from a different set of components each time -- which is what we have now).

The maintenance of this split has already required a few days of work for some packagers and reviewers and it will surely require much more in future. IMO it's also clear that the current patches will break one of the next upgrades in a subtle way so that it will eat at least some of the safed build cycles plus some more work days of Factory users.

---- I can't see how it can be self-supporting and rebuildable into the future. Problems I ran into some years ago was the fact that I didn't delete (various devel packages) from earlier builds -- or, I was told, that I just didn't start with a bare-bones system with every rpm. Some might say, well you don't need to do that with *every* rpm, but then it becomes how do you define the "ever increasing" list of packages that need to be built in isolation from others? At the very least -- I felt, that simply being able to *both* build "CUR" from "Prev" and "Prev-1" and get a working CUR out from each would be a *HUGE* boost in reliability and interoperability, but I was told I was crazy and this wasn't the suse-way to do things At that point, was about when Googles' perpetual-Beta model had started to gain favor because it was just too much work to come out with something in 'cycles' and it was much better just to sell SW as a service so you can keep volunteers running along the ever-expanding stream of software and plug holes manually. As long as new volunteers are cheap enough and no one demands high enough reliability and repeatability, I can see my ideas as being a bit 'quaint'.... but I don't see released software packages (be they small packages or large distro's) growing smaller over time, so it seems either methodology would need to change, or eventually there won't be enough fingers to plug all the holes... Wasn't the old saw "speed, reliability or features, pick 2?" Whereas now you are lucky if you get to pick 1. ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org