On 7/19/2012 5:44 PM, Linda Walsh wrote:

Brian K. White wrote

...

To end on some shred of a positive note, I bet despite all this, if you wanted, you would still probably get help figuring out what YOU are getting wrong and get your package built and even show you the real answer to any questions you have about how gpl is preserved at all points along the way, if you asked that way.

----

You apparently missed the part about the samba problems being resolved and that samba built just fine -- I had no problem with that part...

But this part:

...

Using osc or rpmbuild are just conveniences.

---

Open suse builds using this. If you have things installed, like the package you just built (the devel packages in the samba.spec file, in particular), then there is a bug in the spec file used by rpmbuild. Tries to build full support for everything you have installed. This includes support for the samba database tools ldb, and tdb (and their man pages).

If you have those devel packages installed, the manpages are installed, (as one example of failure), and the build fails due to the build root having unexpected files produced.

In another instance, the presence of the devel package for ldb (I think), led to the ldb tools being installed in the place where binaries get installed rather than a subdir. So again, the spec file fails because it tries to delete the tools out of (check my previous postings -- ) /usr/lib64/ldb/...when the tools they want to delete are in /usr/lib64.

None of these issues are caused by my not knowing how to build -- but are caused by trying to build only parts of the normal samba package and delete others. The presence (installation) of the packages just built would trigger the parts in the script to install supporting files.

By building in a sterile env, you don't get the same behavior as when you build those tools from a tarball.

The normal tarball works, it's the sterilization code that was functioning improperly.

So you are right, it's about my ignorance of a suse-specific build-system that is required to build suse packages. It's not even about rpmbuild (though it uses the spec file that doesn't "prune" the package corrrectly. If OS took the easy route and didn't try to delete files that would normally be installed, this problem wouldn't have happened.

This is why I recommend suse build on systems that they support --- those installed with the release (or prior release) and that have devel packages associated with the product they are building installed.

That's easily a normal expectation -- that suse requires the devel packages of the product you are building NOT to be installed goes against all standard software practice. imagine having to uninstall the linux kernel or sources before you generate it? Would that make sense? Then why should I expect devel packages in samba would cause a problem in building it?

But you are right ... I'm not educated about these new fangled build procedures. There's always new stuff that I don't know... but that's why we have society and customs -- which include established ways of doing things. If you rewrite the rules at every release, of course you can claim they are ignorant - as you've violated normal and/or customary expectations. But you get to be right.

But nothing you described as a problem is either new or specific to suse, and some of what you described doesn't even necessarily sound like a problem or error to me even if you didn't expect it or like it. If the _spec_ file tried to delete files that it didn't create, in your main system's real absolute path, that might be a packaging error, or maybe not, because a package is always designed for some context, and when you use it outside of that specific context, you are on your own. If just for example, you try to install a redhat rpm on suse, it may or may not work, but even if it not only doesn't work but kills your box, it's your fault. Whatever it did would have worked on the redhat system it was meant for. Build procedures have been dynamic since the first shell script or makefile tested for anything. Makefiles got very large and dynamic many years ago. More recently, yet still many years ago, ./configure became the norm almost everywhere not just on linux but anywhere anything gnu-ish was built, and ./configure is 100% dynamic, it's whole purpose is to write out Makefiles on the spot because it's impossible to ship a reasonable one without testing the users system and adapting at the last second to it. I spent a lot of time building gnu-ish stuff on FreeBSD, Solaris, and SCO Open Server. In both Sun and SCO especially, you have a constant problem of native vs gnu varieties of just about everything installed, and almost no Makefiles or even ./configure that correctly guesses what to do out of the box. Actually "correctly" is a wrong term to use, because there is no such thing as "correct" there is only "what I want this time" which no script can predict. They can only have reasonable default logic, and display the actions on screen, and ideally pause just before building to display the proposed configuration to allow you to override it. If I have things installed that the package can optionally use, but for some reason I don't want it to use it, it's absolutely my reasonable expectation to have to do something to actively intervene and make sure the build scripts do what I want instead of whatever the upstream guy put in as a default guess what most people would probably want. Having the build system (any build system, not just rpm or osc) detect the presence of things at build-time and try to use them by default is not remotely a new phenomenon. It's been going on forever. By the time I compiled my 3rd or 4th program ever way back on xenix or even little old pcc on dos (a tiny K&R c, not even ansi) it was a "reasonable expectation" that the build-time environment affected the build process. Having the automatic build system set up a clean environment is in no way invalid. It's the very definition of sound engineering. The concept, not just in a build system, is older than the hills. Why do you think "su" has "su -" option that intentionally throws away the parent's environment and re-runs .profile? Have you never had to get a script working in cron vs in cgi vs as a user vs as root? each of those 4 evironments is different and the same script may only work in one, until the author realizes that context matters. When you write a script and it works, and then you try to stick it in a cron job and it doesn't work, that's not cron's fault for "setting up a sterile environment". That sterile environment is the only way to get any sort of sanity, predictability and consistency. How can you not know this, as a over 10 years experienced linux user? -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org