| |||||||||||||
LSB Not EnoughLSB Not EnoughPosted Sep 10, 2004 2:34 UTC (Fri) by bojan (subscriber, #14302)In reply to: LSB Not Enough by doodaddy Parent article: Bruce Perens: the Linux colonel talks (vnunet)
> Huh, what? Well maybe you know the intricacies of RPM databases and directory structures, plus other potential unknown nuances, but these guys don't want to get a thesis in it.
RPM packages are extremely easy to build. There is a single file, called a spec file, which defines how things are going to be done. Nobody has to get a thesis on any directory structures or databases - various RH distros are very FHS compliant. Also, one can make choices *inside* this spec file to follow minor, distro dependent differences in order to create the RPMS. The spec file can be stored inside a vanilla tarball, which can be turned into binary/source RPMS with a single command. In fact, if designed properly, your build farm running target distros can build new versions of RPMS automatically from this vanilla tarball. Who knows, one may even find companies that do a similar thing and share the build farm resources with them...
If the software that you are building is not open source, then you'll have to do all those minor tweaks yourself, once only. If it is open source, others interested in using it on their favourite RPM based distro can do that for you, thus saving you the effort.
(Log in to post comments)
LSB Not Enough Posted Sep 10, 2004 21:22 UTC (Fri) by gvy (guest, #11981) [Link] Better yet: if you can get the build system under apt, you can use tools to prepare a chrooted build environment, build the package inside it, and have your build and install dependencies linted with build being *repeatable*.
In ALT Linux, there are two such tools -- sandman client/server system (which does far more than that, including integration with VC software, bugtracker and ProjectView but executes package installs as root and thus the access must be controlled to avoid compromise) and hasher tool (which is more self-comtained and is designed with high security in mind).
They are both used for different purposes and they're *published* -- contrary to e.g. RH and SuSE build systems.
I do know that sandman was used with RH7.x plus a few more packages (apt among them).
sandman Posted Sep 14, 2004 0:47 UTC (Tue) by koide (guest, #22687) [Link] It reads like a great tool, but is it ALT Linux dependant, or just apt dependant?
On a related issue, why does ALT Linux get so little attention? It looks like a great alternative.
sandman Posted Sep 15, 2004 7:53 UTC (Wed) by angdraug (subscriber, #7487) [Link] It reads like a great tool, but is it ALT Linux dependant, or just apt dependant? Just APT-dependent, but it also needs a correctly formed package repository. ALT Linux Sisyphus happens to be such suitable repository, but, with varying amount of effort, virtually any RPM-based distro can be adopted for use with Sandman. Sandman was originally developed by Sergey Bolshakov for Optifacio and SaM Solutions to facilitate repeatable builds of a Network Attached Storage system, which is a small (think ~100 MB iso) subset of Sisyphus. ALT Linux didn't manage to adapt it to their whole distribution, so they resorted to a more limited solution, Hasher, which only builds individual packages, much like Debian's pbuilder. Sandman's complexity is one of the reasons why Optifacio offers Sandman-based distribution building as a service: it takes an insider knowledge to set it up. Right now Sergey is re-implementing Sandman to take care of its most fundamental flaw: limited package repository versioning. A team in SaM Solutions is working on a more ambitious build system, which, in addition to proper version control, will add support for arbitrary package formats (Debian, BSD ports, etc.) and plug-and-play build servers. On a related issue, why does ALT Linux get so little attention? It looks like a great alternative. It appears they have no incentive to go international. Besides, outside of Russia, where, as I've already said, ALT Linux has zero marketing, this same niche is nicely filled by Debian, which is bigger, better, and known world-wide. Disclaimer: I am a DD.
LSB Not Enough Posted Sep 15, 2004 7:53 UTC (Wed) by angdraug (subscriber, #7487) [Link] In ALT Linux, there are two such tools -- sandman (...) Typical example of the problem with the ALT Linux business model. Even if it were unintentional, this sentence sounds as if the company is claiming credit to something that it had very little to do with (as in "the company providing network infrastructure for a community project that produced a package repository that is used as a basis for an independent product by another company that actually developed the tool for its customer who agreed to contribute it to the community"). No wonder the customer now requests a "vendor-neutral solution".
LSB Not Enough Posted Sep 13, 2004 5:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link] you guys must be deliberatly trying to misunderstand the problem
the problem is with companies that are not writing open source code, they are not writing infrastructure catagory programs, theya re writing programs for specific tasks and want to continue doing so.
they are willing to support 'Linux' but are not willing to support 20 different flavors of 'Linux'. while we all know that 90% or more of things will work just fine with no effort across all the different flavors, that's not good enough, they have to KNOW that their software will work and they don't want to have to run it through QA 20 times to prove that it will work (and when you have redhat doing non-standard stuff it's very easy to get software that requires non-trivial changes between distros)
if there was a good standard that would let the software function everywhere then this issue could fade away, unfortunantly the LSB takes so long to standardise and covers so little that in practice it's not good enough (I buy software from a company that currently supports 4+ distros and they ignore the LSB becouse it wouldn't help them at all, their management couldn't be sure that someone didn't accidently use a non LSB piece so they still wuld have to test it on every distro)
the problem of commercial software only working on some distros IS a real limitation right now. and now that you can't get a supported OS to run the software on without substantial per-seat licenses it makes it harder to get linux into new places
and once a company buys into the 'enterprise distro' they tend to want to run it everywhere becouse it is expensive in terms of support people to run multiple distros
LSB Not Enough Posted Sep 13, 2004 10:42 UTC (Mon) by hppnq (guest, #14462) [Link] The problem does not seem to exist when it comes to porting apps to proprietary Unix systems, so I fail to see why the Linux case would be exceptionally difficult.I agree that the LSB has not (yet) brought us the standards base we were hoping for. Smart software vendors that want to make their software run on Linux platforms will want to take a good, hard look at their own configuration methods and probably make use of, for instance, autoconf. Just like they would in other cases, by the way. Could you hand me the list of "20 different flavours", or were you just trying to make the problem look bigger than it is?
LSB Not Enough Posted Sep 14, 2004 0:31 UTC (Tue) by koide (guest, #22687) [Link] Because each Linux flavor is comparable to a single proprietary Unix (AFAIK there're no different flavors of solaris, hp/ux, etc.). So supporting Linux is supporting each different distro, and there're certainly more than 20.Thinking on widely used ones you might get to 5 or 6 instead of 20, but the problem is still far from trivial for not trivial systems, especially when you're focused on users which won't be happy compiling each part of the system. A good approach for this issue might be to install in a specific, non standard location while LSB is LNSB, such as Sun's jre (/usr/java), though this doesn't solve library naming issues, so you end up with duplicate libraries (see OpenEV or FGS). You might ask, why not use RPM/apt/whatever? Because then the maintenance cost is huge (updating each part of the system, and tracking each distro specific change, which happens in between versions of the same distro). You can use your package format of choice once you've built the tree in an independant way, of course, but that's against the spirit of packages, I'd say.
LSB Not Enough Posted Sep 14, 2004 8:05 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link] each distro is different enough to be a seperate flavor, and frequently each release of a distro is enough different from previous releases to count as a seperate flavor. with commercial Unix vendors there is less variation between different releases then there is between different linux distro releases (so binaries compiled for Solaris 2.6 still work on Solaris 10, but try to take a binary compiled for RedHat 7 and make it work on Fedora Core2)
it's the same problem as supporting multiple Unix vendors and the software companies don't support all variations on Unix, they support a small handful of them, and in Linux they only support a small handful as well (mostly RedHat releases historicly)
One problem that Linux has along these lines is that it changes faster then the competeing OS's do. that makes the newer linux systems far better, but it makes it harder for the software vendor (even if they only support a single distro)
|
|||||||||||||