So, as might be predicted I suppose, some people wilfully disregarded the thrust of my argument, and turned it into a debate over specific packaging technologies.
OK, so that brings us to the question: what is so bad about SVR4 packaging, really?
I could go on for pages. One of the reasons I found OpenSolaris attractive was the prospect of being able to fix all the bad things with Installation and Packaging in Solaris. Let's takes some of the comments though:
old and clunky
Guilty as charged. Really, it is old. It is clunky. It's been neglected and unloved. It needs fixing. Those reasons alone aren't enough to dismiss it - the key question should be whether it can actually do the job.
missing lots of features
OK, so what features does dpkg have that SVR4 packaging doesn't? That's really the comparison - versus the dpkg or rpm commands.
enabler of dim-sum patching
Completely and utterly false. The problem with Solaris patching lies fairly and squarely in the domain of patching. This could trivially be solved without any changes to tools - either deliver whole packages, or simply institute a policy saying that you can't deliver changes to a package (or related set of packages) in independent patches. This is a process problem, not something inherent to the underlying package system.
Then there are more material objections:
no repository support
Actually, SVR4 packaging does have the ability to fetch and install packages from remote locations. (A crippling limitation of IPS is that it can't do anything else.) What's wrong with this picture is the lack of repositories - blastwave aside. Wouldn't it have been easier to simply make existing packages available on a web site, without having to retool everything?
lack of dependency resolution
As the success of dpkg/apt demonstrates, having your underlying packager do all the work is neither necessary nor desirable. What that does demonstrate is the requirement for more powerful tools above the base packager. Actually, separating the fancy interface from the tools doing the low-level work is probably a really good thing - it enables compatibility of the system over time even if the higher-level tools change, and it enables innovation by allowing independent components to be developed independently.
arbitrary scripting
Actually, one of the key weaknesses of SVR4 packaging is not that it supports scripting, but that the support it offers is pretty poor. there is no real support - there ought to be a strong scripting framework with a well-defined environment, and predefined functionality for common tasks. Oh, and trigger scripts would be nice. Banning scripting (yet allowing it to sneak in through the back door) fails to solve the problem, and encourages bad workarounds.
poor package names
The actual package names are pretty much immaterial. Assigning real significance to them would be false. What matters is that they're unique and follow a scheme. As a user, you might want to install "php" - all that means is that the software studies the package metadata and works out what packages to really install. Actually having a pcakge with that name isn't necessary, and probably not even desirable (it locks you into current names and prevents evolution).
So, beyond a recognition in the codebase that the 21st century has arrived, and the lack of an apt-get/synaptic style front-0end - all of which could fairly easily be remedied - what is really wrong with SVR4 packaging?
18 comments:
My answer to your question: "nothing".
But then again, I'm not an IPS zealot.
package naming was always a huge issue for me in solaris, and it is still a problem in opensolaris.
It's funny you should mention "it locks you into current names and prevents evolution". Remind me why all solaris packages start with SUNW?
I don't know about you, but
'apt-get install sendmail'
makes a hell of a lot more sense to me than
'pkg install SUNWsndm'
Sun didn't write sendmail, or gcc, or screen, or nmap, or many of the packages in opensolaris, why the heck do the package names start with SUNW? It is things like this that annoy the hell out of linux users. Not the shell, not the paths, but stupid crap like 'sndm'. I'm surprised solaris doesn't have packages named SUNWpr~1.
The other thing that always bothered me is that sun couldn't even make sun software easy to install in solaris. Some things like sunstudio and netbeans are now packaged properly in opensolaris, but you should be able to run 'pkg install sun-ray-server'. You should be able to install all sun software on solaris with a single command.
So anyway, back to your original question. I don't know enough about the design of SVR4 packages to say what if anything is wrong with them, but I do think that suns implementation was a complete failure.
Half the time I see someone complain about dependency management someone else responds "But SVR4 packages support dependencies". What the hell good is it that the packages support dependencies if nothing in the implementation even tries to use them for anything?
I agree 100% with Justin. The package names are really ugly. Why have a "SUNW" prefix? Why make the rest of the package name unreadable? Reminds me of the 8.3 filenames of MS-DOS.
Garrett: I wouldn't go so far as to say nothing, as that would imply there's no need to fix anything - and there is huge need for improvement.
Justin: but you're confusing arguments with package names. In the user interface, you install sendmail. What that maps to in terms of the strings of characters used as package names is another matter - it doesn't have to be 1:1, and the problem with forcing the user-friendly names to match the package names is that you lose the freedom to restructure the package layout underneath. (Especially as you ought to be asking for functionality rather than memorising the package names.) Ultimately, package names are an internal implementation detail that the UI should shield you from.
The title sort of implies "if it ain't broke don't fix it", but the discussion is more about "yes it is broke, but why not fix it rather than replace it". I think the answer to the latter is that the only ones who are driving the "fixing" would rather replace it with something more Linux-like. So unless a team of SVR4 developers appear on the scene ready to transform SVR4 packaging into everything it should have been, then we are where we are, like it or not. I don't like it, but I'm not an SVR4 developer either.
I don't get the "dim sum" patching complaint. At least Solaris 10 gets regular security and stability patches. If you are only subscribed to the OpenSolaris release repo (not devel), then you get image updates once in a blue moon. So much for protection from zero-day exploits. Is that really what customers want from a production server?
I'm going to very strongly disagree about the argument for separating the user-friendly names from the package names underneath, because you're not talking about adding a real and necessary logical separation, you're talking about adding another layer of indirection to confuse users and administrators.
In software development terms, you're talking about separating the interface from the implementation. But the interface isn't Sendmail: the interface is "mail transport agent," and the implementation is Sendmail. This is how all modern distributions structure things -- in Debian, Sendmail provides the virtual package mail-transport-agent, while in the world of Red Hat, the MTA's package Provides: smtpdaemon. This is a proper separation of interface from implementation.
Other distributions which have sensible package names already provide the flexibility to change the underlying representation without demanding an inconvenience of the end-user. In the RPM world, this is done through "Obsoletes:" directives. In Debian, virtual packages are designed in order to facilitate the transition. The packaging change silently happens on the back end, and the user never notices a difference.
Technically, what you're proposing is absolutely possible -- "sendmail" could be nothing more than a virtual package which pulls in SUNWsndm. But I'm not convinced, overall, that this is the proper way to approach the situation. In this instance, the Solaris approach is alienating to new users by introducing additional complexity instead of fixing perceived problems. I do understand the backwards-compatibility mission of the Solaris OS, but there's some places where you have to let go of 15-year-old legacy baggage in order to move forward.
Einstein famously said, "We can't solve problems by using the same kind of thinking we used when we created them." For all of the brilliant engineering from Sun and the community, Solaris is doing a lot to continue losing ground to Linux. Ultimately, if Solaris developers want to end up with a bigger market share than NetBSD, they need to take a serious look at what users are complaining about and why.
If there was a reason to ditch the old package system and adopt a completely different one (highest risk) the same analysis can be used in favor o improving the "old" one (lesser risk) since all weak points are known and none is beyond repair.
I use opensolaris and like it but when I run pkgadd -d . * to install a dozen "legacy" packages and contemplate the IPS infrastructure needed instead in my notebook it would be an aberration. It is over engineered.
IPS lost my support when it denied my instruction to replace a package with new bugs for an earlier version after if I figured there was no risk.
Please, give me back the file based package and the option to bypass warnings.
The problem in essence is that we are humans and love starting from scratch ditching what others have done in the past.
It's not a technical issue.
One of the things I love about SVR4 packaging is how easy it is to find what file is in what package eg
grep -i sendmail /var/sadm/install/contents
This is faster and less confusing than IPS eg
pkg search -r sendmail
What I don't like about SVR4 packaging is the reboot factor - adding a package, adding its' required patch which then needs a reboot ( Disksuite / SVM is a good example, or Sun Trunking ). For some production environments, you may only get to reboot once a year (if that).
Recompilation of a package!!!
I know a lot of cases in which source rpms are the way to go. For example:
* I might want to backport a package something from Fedora to RHEL. It might not be included in RHEL
* I need a patch to one of the vendor supplied software packages (realms support in Quagga on RHEL might be an example)
* I need to enable the building of an optional package (ldap support in the RHEL packages is determined by a boolean in the SPEC file and is not included in EL5)
I can live with the weird package naming (for now), but the lack of dependencies and a half sane rebuild system. The current way to recompile a program on Solaris and OpenSolaris is crap.
Right now, I need a newer Samba on Solaris or OpenSolaris, something in the 3.4 series would be preferable. Anything newer than 3.0.34. I also need that Samba to use the same paths and config files that my already running 3.0.34 is. That can be easily upgraded to and from when Sun ships a supported 3.4 version. An RPM file would make that so simple.
(No, CIFS Server does not apply since it doesn't work with a Samba PDC that has an LDAP backend.)
On what grounds do you claim that it is "completely and utterly false" that SVR4 is the enabler of dim-sum patching?
The whole patching model that sun built around SVR4 packaging should be proof enough of that.
Instead of simply treating new versions as new packages, SVR4's "sparse packages" and other ilk create a certain mindset that breeds dim-sum packages.
Yes, almost any software tool or product can be improved upon. But starting over is often better.
If we could just simply improve upon everything instead of starting over, perhaps we'd all be driving quaint improved versions of Ford's Model T today.
If you believe in SVR4, great, the source code is out there have fun improving it. But IPS has already greatly simplified the OS distribution mechanism for OpenSolaris, and I doubt many would ever want to go back.
The 'SUNW' prefix is gradually being dropped from the IPS packages (and will be dropped wholesale at some point), so that's not a particularly good argument for or against anything. Just takes time.
+1 for SVR4
-1 for IPS - ipkg - pkg - package manager or whatever it is being called this week.
also, nothing wrong with solaris package names =)
With SVR4 patching, I can easily back out 1 or 2 patches out of a large set of applied patches. With IPS, I have to try and force an old version of a package to install, and I have to figure out which version that might have been.
I agree, it works just fine, and IPS is, IMHO, wrong from the most fundamental principles up. The OpenSolaris people have become expert and throwing the baby out with the bathwater, and over-engineering new solutions to problems solved years ago.
The problems with SYSV pkgtools are some rotten dependencies (which you get with every packaging system) and the utterly rank patching tools that Sun gave us, each ten times worse than the one before.
PCA gives us a nice front-end for patching, but it's still slow as treacle. I'm sure a new, backward-compatible set of tools could have been written (in C!) but it's too late for that, what with SXCE going any day now.
Actually, once you dig into them, the old pkg* tools have a fair bit of functionality, I've done all sorts with them over the years!
There is nothing principally wrong with SVR4 packaging. In fact, it has been used by professional (emphasis on professional) system administrators for decades, and it held up and still holds up, such as it is.
Not only that, but SVR4 packaging has some really awesome features, like class action scripts, which enable pkgadd(1M) to modify bits in-flight to disk!
No other software management subsystem has that functionality.
A private datastore in the form of ${PKGSAV} is another nice feature, and datastream packages retrievable over HTTP protocol are one step away from automatic dependency resolution!
Also, there is nothing wrong with SUNW* package names. In fact, if all the packages were renamed to something simplistic like "sendmail", what would all of you do if you needed to roll your own sendmail? You'd have to prefix it with something, since delivering bits in /usr is off limits, as an upgrade is likely to overwrite your own sendmail!
(sendmail is just an example; feel free to replace it with the software name of your choice.)
So distinctive ABCDpackage-something names are a must, not an optional feature.
What could be improved about SVR4:
- -d http://... could look for other packages at the same URI and automatically resolve dependencies;
- virtual capabilities could be added, for example, a package may claim it provides MTA capability... RPM has this, and it's really nice;
- concatenated datastream packages could be treated as a cluster (physical package clusters instead of metaclusters);
- namespaces in the way of IRIX's eoe.sw.ssh.(man|sw|doc|libs) would be really nice, but not required, however, namespaces would make bundling possible, and make SVR4 really powerful.
The automatic dependency resolution is the most important requirement, and I believe it could be implemented relatively simply as a backend graph algorithm, which is well understood, and in fact, I might attempt to do just that. All that's needed is code that looks to wherever pkgadd -d http://... is pointing to at the beginning, and scans all the "depend" files and builds a dependency graph.
That is the lowest hanging fruit, and in the wake of Solaris 11 coming with IPS, it's a worthy goal to pursue.
Anything is better than IPS.
As for "dim sum" patching, that is a self-inflicted pain that has absolutely nothing whatsoever to do with SVR4 packaging! Sun could have opted to simply release newer revisions of packages with fixes, but since they did not invest the time to implement a version check mechanism (or scheme), they never did that.
Well, that's Sun's fault, not the tools' fault!
There is nothing principally wrong with SVR4 packaging. In fact, it has been used by the PROFESSIONAL (emphasis on professional) system administrators for decades, and it held up, such as it is.
Not only that, but SVR4 packaging has some really awesome features, like class action scripts, which enable pkgadd(1M) to modify bits in-flight to disk! No other software management subsystem has that functionality. A private datastore in the form of ${PKGSAV} is another nice feature, and datastream packages retrievable over HTTP protocol are one step away from automatic dependency resolution!
Also, there is nothing wrong with SUNW* package names. In fact, if all the packages were renamed to something simlistic like "sendmail", what would all of you do if you needed to roll your own sendmail? You have to prefix it with something, since delivering bits in /usr is off limits, as an upgrade is likely to overwrite your own sendmail!
(sendmail is just an example; feel free to replace it with your choice of software.)
So distinctive ABCDpackage names are a must, not an optional feature.
What could be improved about SVR4:
-d http://... could look for other packages at the same URI and automatically resolve dependencies
- virtual capabilities could be added, for example, a package may claim it provides MTA capability... RPM has this, and it's really nice
- namespaces in the way of IRIX's eoe.sw.ssh.(man|sw|doc|libs) would be really nice, but not required, however, namespaces would make bundling possible, and make SVR4 really powerful.
The automatic dependency resolution is the most important requirement, and I believe it could be implemented relatively simply as a backend graph algorithm, which is well understood, and in fact, I might attempt to do just that. All that's needed is code that looks to wherever pkgadd -d http://... is pointing to at the beginning, and scans all the "depend" files and builds a dependency graph.
That is the lowest hanging fruit, and in the wake of Solaris 11 coming with IPS, it's a worthy goal to pursue.
Anything is better than IPS.
Post a Comment