ok, now the reply to the rest of Bart's email :-) Bart Smaalders wrote: > Philip Brown wrote: >> >> >>> 2) scripting interfaces for package creators are toxic >> >> They are ugly, yes. But eliminating scripting, is not a good >> "solution" for this. >> > This is an refutation w/o a counter proposal.
"allow scripting" is an on/off switch. Either allowing scripting is neccessary to fully handle "complex" package installs that sun will never anticipate... or it isnt. From my years of 3rd party packaging experience, I assert that it is required. However, as for a proposal to address the specific issues you brought up...: > it prevents reversible packaging, Yes, it does. Leave it up to the vendor to decide which is more important to its customers: "reversible packaging", or a more user-friendly install. At the system packaging level, you could easily have mechanics of, "packages are 'reversible' by default, unless the 'i have a script' flag is on. in which case, it isnt". Likewise, for the "nightmare of testing" issue. Provide alternatives for what you THINK is "better for the customer". But then let the CUSTOMER decide what is better for them. To do otherwise, is poor customer relations. >it needs to be revisited for > each new installation context (eg zones, virtualization), I would like to know in more detail how IPS "solves" this issue, before I can make an informed counter-proposal in this area. > Restricting actions to those that are needed to in order to > restart/reboot and then handling all other needed changes in > normal run-time context is a much simpler technique, and > will greatly reduce the testing matrix. I'm not quite sure I fully understand what you are saying here... I'm not sure where we are actually differing in opinion here. That is to say, I would very much like to see a defined API from sun, of "This is what you do if you need something done at reboot. That is what you do if you need something done otherwise". As I wrote in my "actions vs class action scripts" email... the main problem in this space, is that sun does not provide ready-to-use scripts for how to do this sort of thing, in the existing SVR4 space. If Sun did, then people would use them. People dont WANT to write customized everything. The biggest problem is that Sun doesnt offer them an alternative for what they need to do. >>> 3) versioning is undefined >....the packaging system cannot do anything w/ the information in the > version string, since it doesn't have any meaning. You assert that svr4 > packaging works, since I can layer stuff on top to fix all the problems. > That layering is _exactly_ the problem - I don't want a packaging > machine cobbled together out of various pieces that don't do the > whole job. I want a system that's integrated and tested and was > designed as a whole. "Layers are for cakes, not for software". That is going to an extreme. You seem to be saying, "if it isnt all encapsulated in a single monolithic piece of software, then it is layered, and layered = bad". Almost any software is typically "layered" at the code level, through internal APIs. IPS itself is "layered", in that it has multiple python files, each with its own interface! Would it somehow be "better", if it were all glommed into a single .py file? The bits call each other through python calls. What makes it somehow "worse", if some internal "bits" to a packaging system, called each other through fork() and exec() ? Another comparison: SMF, is "layered", to my perspective. It has separate "admin", "cfg", and "status" executables, or "layers". When are you going to fix that? ;-) Also.. sometimes, layering is GOOD for testing! Sometimes, it's really good to _know_, "the bottom layer is rock solid... it must be a problem in the interface layer" >> Changing gears a little; >> In my opinion, the whole approach to patching+SVR4 should be changed, >> to make "a patch" be a mechanism to update >> SUNWfoo VERSION 1.2.3_FCS10rev1 >> >> to >> >> SUNWfoo VERSION 1.2.3_FCS10rev4 >> >>.... > Except that now I have to: > > invent pkgupgrade already done, with pkg-get? :-) > redeliver 500M of staroffice to fix a one line typo in a doc file no, that's what (sane) patching could be used for. There's also a tradeoff, in granularity. if you want update granularity down to the file level.... then that means, every time you tell your system, "scan for updates"... that instead of comparing versions on 500 packages... you will now have to compare versions of 50,000 files individually. That would seem to be a significant use of resources. > change svr4 package dependencies to include version information oh? I dont see it that way. It depends on what model you use, for your "network distribution/update" layer. If you also have the concept of an "image", then all that is required, is to check, "are all my relevant SVR4 packages at the same version level as [the remote "image"]?" (or to put it in blastwave terms, "Are all my packages up to date with the latest 'catalog'?" :-) It's easy. It requires no changes to svr4 package dependencies. And it's been working well for 5 years. > still solve the zone upgrade issues again: I'd like to know in more detail how IPS solves the zone upgrade issue. then I'll be able to comment better on the SVR4 perspective in that area. >> > 4) metatdata (.clustertoc, pkghistory) is stored elsewhere >>> 6) networking support is laughable >>> 7) no dependency following >> >> easily doable at a higher level. cf: blastwave.org >> > So anyone using svr4 packages will still have to manually compute the > transitive closure of their packaging dependencies? I'm unclear on why that would be required. If you target an "image" (or specific "catalog" revision), then all you usually care about is, "am I up to date?" > Zones and virtualization, plus the more rapid evolution of Solaris, are > the bales of hay that have broken the back of sv4r packaging. It just > doesn't work well enough anymore to entertain releasing another version > of Solaris w/ a 10 year support tail using it. > well, you're already stuck with doing the engineering effort, of supporting solaris 10, + zones, + SVR4 packaging, with a "10 year support tail." So whatcha gonna do about it? :-D I dont think telling all the existing sol10 customers, "convert everything to IPS", is gonna fly too well... _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
