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