Mathiasdm
January 3rd, 2007, 11:24 AM
First things first: I like the way Linux applications are installed (apt-get, emerge, yum and such are great tools).
However, it would be nice if things were standardized a bit more (without taking away choice, of course!).
The Free Standards Group are discussing a standard API for package management. This way, if you wish to install a package that's not in the repositories, you could still easily install it (and have it registered in your package management program).
http://www.linux-watch.com/news/NS4586903228.html
Jan. 02, 2007
Installing a new application on Linux can be challenging, even for experts. Now, the LSB (Linux Standard Base) project and its parent organization, the FSG (Free Standards Group), have a plan for how to make it easier for both users and developers.
Last month, key people in the Linux software packaging world and ISVs (independent software vendors) got together in Berlin, Germany to discuss the future of Linux application packaging. The group decided to create a bridge between the various software package installment programs that the Linux distributions support and what the ISVs need to support Linux.
According to Ian Murdock, CTO of the FSG and chair of the LSB, what ISVs want is "to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows."
To give the ISVs what they wanted, the Red Hat and Novell maintainers of RPM and the authors and maintainers of APT, yum, alien, and klik quickly decided that the best real-world solution was to construct "a single API (application programming interface) that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences," according to Murdock.
The Berlin group also decided that the API should have a limited scope, since "providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable," Murdock continued. This can work, according to Murdock, because, "Fortunately, the ISVs don't really need much. At the most basic level, an installer just needs to be able to query the system to see if it's LSB compliant, and if it is, what version of the LSB it's compliant with; and it needs to be able to 'register' with the package system, so the package system knows about it, including what files it has installed."
Then, since the assumption is that the distribution will be LSB compliant, "We don't have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support -- components can extend the LSB, and applications can depend on those other components being installed-but we're talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with," added Murdock.
Given the limited duration of the meeting, the group didn't come up with a complete solution. For example, the issues associated with software un-installation were barely touched, and how applications go about changing the system configuration still needs discussion. Still, it was a start. Murdock reported that "Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets."
To further the development and support of this API, the FSG has created a Packaging Workgroup and is relaunching the LSB packaging mailing list. There is still, Murdock concluded, "plenty to be done."
-- Steven J. Vaughan-Nichols
Edit:
Ian Murdock's opinion on package management:
The current state (http://ianmurdock.com/?p=388)
Software installation on Linux: Today, it sucks (part 1)
As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.)
One of the quotes I’ve had queued up for a long time is this one from Jon Udell:
I have a confession to make. Sometimes, when I’m trying out an unfamiliar open source component, I cheat. Even if the software I’m working on will deploy to Linux, I’ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.
He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows.
Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes.
In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script.
Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable.
Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now.
Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev.
Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs?
At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.)
After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer).
Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.)
Oh, well. At least I didn’t have to check for viruses!
Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used.
Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things.
However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively.
Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…
The future... (http://ianmurdock.com/?p=391) (pretty much the same as the original article)
However, it would be nice if things were standardized a bit more (without taking away choice, of course!).
The Free Standards Group are discussing a standard API for package management. This way, if you wish to install a package that's not in the repositories, you could still easily install it (and have it registered in your package management program).
http://www.linux-watch.com/news/NS4586903228.html
Jan. 02, 2007
Installing a new application on Linux can be challenging, even for experts. Now, the LSB (Linux Standard Base) project and its parent organization, the FSG (Free Standards Group), have a plan for how to make it easier for both users and developers.
Last month, key people in the Linux software packaging world and ISVs (independent software vendors) got together in Berlin, Germany to discuss the future of Linux application packaging. The group decided to create a bridge between the various software package installment programs that the Linux distributions support and what the ISVs need to support Linux.
According to Ian Murdock, CTO of the FSG and chair of the LSB, what ISVs want is "to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows."
To give the ISVs what they wanted, the Red Hat and Novell maintainers of RPM and the authors and maintainers of APT, yum, alien, and klik quickly decided that the best real-world solution was to construct "a single API (application programming interface) that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences," according to Murdock.
The Berlin group also decided that the API should have a limited scope, since "providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable," Murdock continued. This can work, according to Murdock, because, "Fortunately, the ISVs don't really need much. At the most basic level, an installer just needs to be able to query the system to see if it's LSB compliant, and if it is, what version of the LSB it's compliant with; and it needs to be able to 'register' with the package system, so the package system knows about it, including what files it has installed."
Then, since the assumption is that the distribution will be LSB compliant, "We don't have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support -- components can extend the LSB, and applications can depend on those other components being installed-but we're talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with," added Murdock.
Given the limited duration of the meeting, the group didn't come up with a complete solution. For example, the issues associated with software un-installation were barely touched, and how applications go about changing the system configuration still needs discussion. Still, it was a start. Murdock reported that "Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets."
To further the development and support of this API, the FSG has created a Packaging Workgroup and is relaunching the LSB packaging mailing list. There is still, Murdock concluded, "plenty to be done."
-- Steven J. Vaughan-Nichols
Edit:
Ian Murdock's opinion on package management:
The current state (http://ianmurdock.com/?p=388)
Software installation on Linux: Today, it sucks (part 1)
As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.)
One of the quotes I’ve had queued up for a long time is this one from Jon Udell:
I have a confession to make. Sometimes, when I’m trying out an unfamiliar open source component, I cheat. Even if the software I’m working on will deploy to Linux, I’ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.
He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows.
Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes.
In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script.
Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable.
Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now.
Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev.
Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs?
At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.)
After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer).
Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.)
Oh, well. At least I didn’t have to check for viruses!
Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used.
Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things.
However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively.
Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…
The future... (http://ianmurdock.com/?p=391) (pretty much the same as the original article)