Privet !<br><br><br><div class="gmail_quote"><div class="im">On Thu, May 9, 2013 at 1:45 PM, Jim Klimov <span dir="ltr"><<a href="mailto:jimklimov@cos.ru" target="_blank">jimklimov@cos.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 2013-05-09 13:06, Andrzej Szeszo wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The process you have described sounds a lot like OI's original plan. It<br>
didn't work out. There was too much baggage. No one was willing to spend<br>
time learning it. It was just too ... ugly.<br>
</blockquote>
<br></div>
It's possible to try it differently this time :)<br></blockquote></div><div><br><br>One of the main reasons why it is complicated to build OpenSolaris, is definitely IPS itself.<br>Rather
than just the fact, that almost every of the consolidations has
different ways in which they implemented their build, with different
locations for Makefile.master, a different directory hierarchy versus
even with pkgbuild and .spec files.<br>
To resolve deps, that's cpu intensive like little else and also error prone.<br><br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One way or another, in these consolidations we have tons of source<br>
code, which, one way or another, need a process to build them.<br>
<br>
Even if the system of build scripts, spec recipes, makefiles and so<br>
on would be changed to something else, just to develop this new build<br>
logic and to check validity and comparability of the resulting packages<br>
we (individual developers) need to be able to build it "the old way"<br>
and "the new way" (whatever that would be). AFAIK, very few people<br>
know what to do to create the binaries and packages in the old<br>
techniques, which makes it problematic for others (not "in the know")<br>
to start improvements or from-scratch rewrites.<br></blockquote></div><div><br><br><br>Starting
in 2007 I had the same dream. And I even started and made some progress
(still have it somewhere in my backup archives). My idea was, to merge
all consolidations (for MartUX) into one single Makefiles system, namely
into that of Sun's X11 group, as developed by Alan Coopersmith and team
on the basis of OS/Net's Makefiles. I think Moinak Ghosh has worked on
something similar even before me (as I learned later), and has come
further. So I stopped the effort. I recall that he released this on <a href="http://belenix.org" target="_blank">belenix.org</a>
a long time ago. If I'm corerct he once called it DistroGenerator
(don't confuse this with DistroConstructor, which, btw, HE also invented
long before Sun took err stole it).The first so called "Indiana" was in
fact BeleniX in 2007!!! And is was completely unfair and injust that
Sun had hired that Ian Murdock destructor purely for marketing reasons
alone, and that he was permitted to give the stolen BeleniX his name.
This is the primary reason why those that remember all this (including
myself) could never be happy with the name "ind_IAN_a". <br>
<br><br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Of course, some architectural overview or general framework for all<br>
consolidations of what we want to achieve as the new build system<br>
(i.e. "conforms to this list of technical requirements: A, B, C... Z")<br>
would be needed.<br>
<br>
I may be wrong to think that ability to build the whole beast in the<br>
old ways is useful to make the new building technology, but lack of<br>
it also hinders an ability to make new spins of the whole OI distro<br>
or just updated package repos, as one other commonly-requested useful<br>
result of the overall OI project. So far most users can rebuild the<br>
"kernel" part (illumos-gate) of their installations and third-party<br>
code like updated sendmail, apache or whatever they need to update,<br>
rebuilt and installed in traditional unpackaged ways into alternate<br>
paths or even overriding the system binaries, but that's about it.<br>
And this is wrong, especially for SOHO farms of several OI machines<br>
or zones which could otherwise reuse the in-house updated packages<br>
automatically and properly :)</blockquote></div><div><br><br>I made bad experiences with IPS.<br>With SVR4 all this is a ton (1000kg!) easier, more transparent, and more fine grained.<br>You can touch every package, even inside the repo, by hand.<br>
It is not a database like monster, black box or even rather black hole,
that IPS appears to be, in my personal view (sorry about that).<br><br>Example:
If you want to change a single package, maybe even a single file, or an
arbitrary number of packages, it is always easy, transparent and
doable: <a href="http://svr4.opensxce.org/sparc/5.11/" target="_blank">http://svr4.opensxce.org/sparc/5.11/</a><br>
<br>For example, if a new Firefox comes out, many users care about "the newest version, yeah".<br>Here is the SVR4 way: <br><br>0.) Delete <a href="http://svr4.opensxce.org/sparc/5.11/sunw_firefox-18.0%2cREV%3d110.0.4.2013.01.10.17.25-SunOS5.11-sparc-SUNW.pkg.gz" target="_blank">http://svr4.opensxce.org/sparc/5.11/sunw_firefox-18.0%2cREV%3d110.0.4.2013.01.10.17.25-SunOS5.11-sparc-SUNW.pkg.gz</a><br>
<br>1.) Build FF or take the Oracle supplied redistributable bins from
China and create the package by just hitting make install in my prepared
SUNWfirefox subdir, this creates the SUNWfirefox package<br><br>2.) With a plain flat miniscript from another dir convert it into the <a href="http://pkgtool.net" target="_blank">pkgtool.net</a> format<br>
<br>3.) Copy over or sftp upload the new file to <a href="http://svr4.opensxce.org/sparc/5.11/" target="_blank">http://svr4.opensxce.org/sparc/5.11/</a><br><br>4.) ssh into <a href="http://svr4.opensxce.org/sparc/5.11/" target="_blank">http://svr4.opensxce.org/sparc/5.11/</a> and run bldcat<br>
(if the server hosting <a href="http://svr4.opensxce.org/sparc/5.11/" target="_blank">http://svr4.opensxce.org/sparc/5.11/</a> is not a Solaris machine, just do the previous steps but take your local mirror of <a href="http://svr4.opensxce.org/sparc/5.11/" target="_blank">http://svr4.opensxce.org/sparc/5.11/</a> and run bldcat there, then simply upload the two catalog files to the real repo site.<br>
<br>To complete all the necessary steps as mentioned above takes a single person just 30 minutes or less.<br>No mogrifying, and no problems.<br><br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Individual gates provide some semi-automated ways of building things. I<br>
don't know anyone who managed to automate them all though. No one was<br>
able to provide equivalent of "make world" to build complete OI to date.<br>
</blockquote>
<br></div>
There are occasional requests on the list from people who are willing<br>
to give it a try, and look at the same bits of knowledge from their<br>
perspective. If those are shared, including the info on what works<br>
and what doesn't and hypotheses on why it doesn't, it is possible<br>
that just by sheer increase of the number of eyes, hands and brains<br>
aimed at parts of the problem, it would budge and give in :)<br>
<br>
After all, most "manual" administrative tasks can be scripted with<br>
mega-scripts of logic based on practical observations (do this, check<br>
that, don't do this if...). If someone formulates the problems in<br>
English, others can translate them to bash or perl or make scripts...<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is no doubt Martin Bochnig has a lot of expertise in putting<br>
operating systems together. I got impression that he was heavily<br>
invested in SVR4 based systems though. </blockquote></div></blockquote></div><div><br><br>True.<br><br> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OI may not be an interesting<br>
project for him as it will probably remain IPS based for the time being.<br></blockquote></div></blockquote></div><div><br><br>Well, as said last winter, it would be interesting.<br>And I have very good feelings about OI.<br>
The problem is simply, that I have all hands more than full with restarting OpenSXCE.<br>
And also I think that SVR4 in connection with Blastwave style pkgutil
can serve the users' wishes to have a repo in the cloud, while at the
same time being much faster and also more transparent during install
time, and certainly a 100 or 1000 times faster during development and
repo maintenance.<br>
<br><br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
<br></div>
I did lose track of what he implemented in the end, </blockquote></div><div><br>I gave a short summary on my twitter account last night.<br><br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but I think his<br>
builds did rely on existing IPS manifests, and he had fixed quite a<br>
few, and the SVR4 packages were built using automated backports of<br>
the IPS metadata. IF this assessment is correct, </blockquote></div><div><br><br>Not correct.<br>Here is why:<br><br><a href="http://openindiana.org/pipermail/openindiana-discuss/2012-December/010921.html" target="_blank">http://openindiana.org/pipermail/openindiana-discuss/2012-December/010921.html</a><br>
<br><br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">then it is more a<br>
matter of taste - which packaging system the resulting OI distro<br>
would use, either format would come from same sources.<span><font color="#888888"><br>
<br>
//Jim Klimov<br>
<br>
</font></span></blockquote></div></div><br><br><br>Jim, well: In the earlier JDS sources exactly this was indeed possible.<br>You build them like the newer ones, the *.spec files with pkgbuild.<br>And on the pkgbuild cmd line you specify if you want to generate IPS or SVR4 packages.<br>
So there already is one stable approach in existence and we with our few
men should not reinvent it. So if OI really wants to stick with IPS, we
could technically still build OI and OpenSXCE from the very same
sources. As long as we merge all other consolidations into JDS's
pkgbuild framework.<br>
<br>Even if not: It is still possible for the two to co-exist in a much
easier way. Take OS/NEt aka Illumos: For IPS you have a subdir called
pkg, for SVR4 you (or at this time I) have the subdir pkgdefs.<br><br><br><br><br>
<br>poka,<br> %martin<br><br clear="all"><br><br>- <br>regards<br><br>%martin bochnig<br> <a href="http://svr4.opensxce.org/sparc/5.11/" target="_blank">http://svr4.opensxce.org/sparc/5.11/</a><br> <a href="http://opensxce.org/" target="_blank">http://opensxce.org/</a><br>
<a href="http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD" target="_blank">http://wiki.openindiana.org/oi/MartUX_OpenIndiana+oi_151a+SPARC+LiveDVD</a><br> <a href="http://www.youtube.com/user/MartUXopensolaris" target="_blank">http://www.youtube.com/user/MartUXopensolaris</a><br>
<a href="https://twitter.com/MartinBochnig" target="_blank">https://twitter.com/MartinBochnig</a><br>