Packaging and installation issues for Linux and LSB –

Last week I petitioned for tangible, far-reaching results from Linux Standard Base and hope you, too, will demand results in a timely manner. Among many other things, I asked for a comprehensive self-hosting sample implementation of an LSB-compliant Linux distribution. In plain language, that means I want a standard Linux distribution anyone can install and run. Every commercial and nonprofit Linux distributor would start with this standard, and then add the unique kind of value that does not cause incompatibilities.

Chief executive of TurboLinux Paul Thomas outlined a similar vision recently in an article published by CNet (see Resources for a link). In it, he says he envisions the consolidation of Linux distributions so that everyone ends up using the same basic distribution. Personally, I don't care whether the result comes from commercial consolidation or through standards. All I care about is that we get there.

Linux Standard Base currently does not officially plan to deliver a comprehensive self-hosting standard implementation. Depending on whom you talk to, a standard distribution is either a terrific or horrific idea. links home

Best of

The Legacy Files

The Penguin Brief

Version Control

Linux links

Linux forums Eschewing a self-hosting standard distribution is a big mistake that leads to other mistakes. For example, if one could agree on a self-hosting standard, one could solve a lot of packaging and installation problems that the LSB does not address. Right now LSB is going to declare RPM the standard package format and leave it at that. By doing so, LSB is missing the point of what users and developers really need. They don't need to be told what package format to use. They need a cohesive and intelligent plan for installing and updating applications.

I'm talking about a policy on how applications must be installed and configured, how dependencies are defined, and how the installation and removal process should address unmet dependencies. By dependencies, I mean other applications and libraries that an application may need to run properly. LSB should also define the protocol for updating those application libraries, adding new versions of libraries, and then establish rules on how applications must look for and use those libraries.

The Debian GNU/Linux installation system is still a work in progress, but it could be an excellent start toward solving those types of installation issues. Debian's system creates a catalog of all the applications that exist on any number of servers or other storage resources that you define. When you use the apt-get command to install a package, it automatically finds where to get the package you want and attempts to resolve the package's dependencies. If necessary, it removes whatever conflicting versions you may have on your system and installs the correct newer versions. Then it installs and configures the package you want.

LSB should start with the above system and add things such as a finer granularity of upgrade choices. (I'm told that the Red Hat Network has that kind of granularity, but I haven't tried it yet. I'm also no expert with Debian, so it may have a degree of granularity of which I am not aware.) Then LSB could add checkpoints and rollback to the process to give an administrator the ability to recover from unforeseen consequences of performing an upgrade. Of course, LSB should strive to prevent rollbacks from becoming necessary. Naturally, that would require a Herculean effort, but it shouldn't be much more difficult than what the Debian maintainers are already doing.

Now if you think that through, you'll see that the whole approach is only practical if every distribution plays by the same comprehensive set of rules. And those rules far exceed the tiny set of rules currently slated for the LSB 1.0 specification. So for that plan to work, LSB needs to dramatically expand its scope to encompass (you guessed it) a self-hosting standard distribution.

In addition, the plan will only work if an organization such as the LSB, or someone else in cooperation with LSB, hosts a server farm where anyone can get the packages required to resolve dependencies. The server farm will have to host existing and future versions of libraries and packages to guarantee that someone will be able to roll back properly in the event of a problem.

Are there other issues you believe LSB should address? Let me know.

Pesky carriage return and line feed pairs

Thanks to the many people who responded to my call for help in figuring out why my copies of the Java SDK were downloading with carriage return and line feed pairs. The problem turned out to be caused by the Squid proxy and Web cache manager, and how it dealt with the file name

<font face="Courier"></font>

I assume Squid sees the

<font face="Courier">.sh</font>
file extension and assumes the file is a shell script. Squid then treats it like a DOS or Windows text file and inserts the cr/lf pairs wherever it finds a single line feed. I am told Squid does that because it cannot discriminate between a Windows and a Unix client, so it defaults to Windows.

I'm reluctant to excuse Squid for that particular behavior. If it is indeed recognizing the

<font face="Courier">.sh</font>
extension, Squid can assume it is more likely serving a Unix client than a Windows client. But I'm not sure if that would fix the problem anyway. What Squid really needs is to ship the file over as a binary file, not a text file. And the
<font face="Courier">.sh</font>
is usually attached to a text file, regardless of whether you're talking to a Windows or Unix client.

So the stupidity award really goes to Sun in this case. Sun ships its Java in a

<font face="Courier">.sh</font>
script format to force you to agree to its license before you unpack and install Java. That is silly. If you're downloading the file from Sun, you already had to agree to the license to get to the download page.

Anyway, if you're using Squid, you can avoid that problem in a number of ways. You can reconfigure your Netscape client to connect directly to the Internet, download the file, and then tell Netscape to use the proxy again. As a second alternative, you can download the file using HTTP instead of FTP. Finally, you can probably reconfigure Squid to recognize the

<font face="Courier">.sh</font>
extension and download the file in binary mode, but I haven't investigated how to do that because the other methods are much more expedient.

Poetic justice

I couldn't let this week go by without calling your attention to one of the best examples of poetic justice to occur in many years.

Jeff Merkey, CEO of Timpanogas Research Group in Orem, Utah, has been working with Microsoft to create, among other things, a version of Novell Directory Services (NDS) for Linux. If you follow the story to its conclusion, you can see that Microsoft's intent was to neutralize the intellectual property value of NDS to give Microsoft a free method to woo customers away from Netware.

But when Microsoft decided it didn't want Jeff Merkey to create an NTFS module for Linux -- one that would allow Linux users to read and write to NTFS partitions -- Microsoft threatened Merkey. Merkey responded by returning Microsoft's source code and canceling his contract. Merkey did that with confidence, as demonstrated by his comment about Microsoft, published in The Register on Sept. 27, 2000:

"The last thing they [Microsoft] need is for me to take the stand and testify as to what kind of deals they offered to get us to leave Novell in 1997 and divide the NetWare markets by using the Linux IP Laundry-Mat to launder Novell's NDS for their consumption."

A few days later, on Oct. 1, 2000, Linux Today printed the following comment from Merkey:

"Microsoft has apologized and withdrawn their statements. We are very happy this thread ended on a happy note, instead of in court. Microsoft will take no action against us for NTFS development on Linux, which can now proceed without concern."

It looks as if the ultimate bully got a taste of its own medicine. But would Merkey have had any leverage if it weren't for the Department of Justice investigation and pending appeal? I've always thought that if anyone deserves credit for the success of Linux, it's Joel Klein, the assistant attorney general in charge of the Microsoft antitrust case.


ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon