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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org