* James Carlson <james.d.carlson at sun.com> [2007-09-12 12:46]: > Stephen Hahn writes: > > This project seeks to develop a software packaging system that is able > > to update, in a safe and predictable fashion, a variety of software > > components across a range of system install contexts. The image > > packaging system is intended to solve a collection of software > > update-related problems, as outlined in [1 - 5]. > > I very much like the idea of getting rid of scripting within the > packaging mechanism; it's the source of a lot of trouble. > > However, I have questions about this proposal: > > - To what extent would we be forcing others to adopt this now- > [Open]Solaris-proprietary packaging system? If the project > guarantees a shim layer of unbroken SysV packaging support, then > that's probably a good thing. Otherwise, I think the proposal > should address the costs forced onto others: those who end up > having to deliver software twice (once for older environments, > once for newer, and probably not bothering to do at least one of > those).
The current prototype can convert SysV packages to the new form, recognizing resources it has mechanisms for (and dropping the scripting). I'm going to skip over "a shim layer of", and state that there are numerous ways to allow a software publisher to defer their decision to migrate to a new form. Whether any of these constitute guarantees... I'd like to get a little further before recommending a particular compatibility/migration to any particular distro. > - What of existing solutions? I see a lot of discussion in the blog > postings about the problems we've had with our constrained use of > System V packaging, but is the team completely dedicated to > creating yet another packaging system? What about other systems > that already exist? Were they evaluated or is that work still to > be done? I'd expect that we're in better shape in terms of > layered applications (package managers) if we can adopt an > already-implemented solution, even an "imperfect" one, rather than > designing a new albeit perfect one. At this point, completely dedicated. Members of the team have been examining the various competitive packaging systems for a year, in the context of patching issues, virtualization, and manageability for Solaris. We are aware that there are costs to a new effort; there are also costs to attempting to wrest any of the existing systems into an acceptable shape. > - What becomes of the versioning problem? We have some really hard > problems here that are neatly illustrated by our current patching > problems: > > 1. We don't always know what bits depend on what other bits. > If we did, then patch contents would always be "correct" > and wouldn't require manual error-prone tweaking. They're > not always correct, and patch generation is a human- > mediated process. > > This means that "version 2 of package A depends on version > 1 of package B" is an incomplete mechanism. We're going to > need tools and processes that allow us to identify those > dependencies in a fine-grained way. This is a particularly > difficult problem when the dependencies are not of the > trivial symbol-table type, but are rather of the behavior > type. Does this project generate those practices that make > individual package versioning safe enough to use? We believe that we can give guidance on completeness for a variety of dependency types to reduce the chances of error. Given our automated analysis of the existing package set for only the ELF objects, we know that the existing process is very much incomplete. (That is, there are both missing and unnecessary dependencies--and runpaths, for that matter.) We've incorporated some of the patch difference analysis into the base functionality of the prototype, so that we actually do know what files change (from delivery to delivery) and, for some classes, if they changed in a significant or non-significant fashion. > 2. We currently rely on the fact that consolidations are all > built all at once in a coordinated action, and then > delivered as a matched set. This lets us ignore some > complicated problems that occur when interfaces used across > projects are allowed to have arbitrary and not-necessarily- > compatible change. The system will allow groups of packages to be co-delivered with matched versions (and with constrained version flow). Departing from the version flow of those groups will require an explicit act by the deployer. > One way around this would be to say that each consolidation > delivers just one new-fangled package: ON is a single lump of > stuff, at least until we take pains (over a long period of time, > probably) to refactor ON into smaller parts. Is that part of the > future plan? I would expect that consolidations would use the group packages to do something similar to this, although I expect few would use a single package to represent their various deliverables. > - How do we avoid getting caught up in the Debian packaging > dependency problem from hell? I used to run Debian at home, and I > ran screaming from it when I ran into numerous "impossible" cases > -- essentially points where I wanted both A and B, but each > required an incompatible version of some common package (C), and I > had to "pick" one to run and forget the other. I ended up with a > confusing mass of locked version numbers and a really good reason > to install Solaris instead. > > Perhaps a problem of my own causing (I shouldn't have used the > relatively fresh stuff in "Unstable" when the "Stable" branch had > comfortable mold on it), but it points back to having fairly tight > controls on the build environment used for each component (in > order to get common dependencies to work out), and thus a clear > set of new policies to go along with a new packaging project. This kind of coordination is something that having accurately operating consolidations brings to a product. The packaging system can advertise incompleteness, collision, and some losses of compatibility so that users aren't victimized by a consolidation asleep at the wheel. Furthermore, I would expect that an ideal distro's release repository would only publish software that had gone through such a process. These are all good questions; as the project proceeds, I believe we'll learn if these incomplete answers become acceptably complete. - Stephen -- sch at sun.com http://blogs.sun.com/sch/
