Philip Brown wrote:
> Bart Smaalders wrote:
>> Just a few things that are broken w/ SVr4 packages:
>>
>> 1) there is no upgrade
>
>
> Would be useful. Yet, this could be solved by sun providing actions(?) for
> this sort of thing. Or just defining some standards.
>
The project team is providing actions in IPS. Actions in svr4 packages
are obviously possible, but then it isn't svr4 packaging anymore, is it?
> blastwave has solved this issue, by defining internal packaging standards to
> preserve package state across upgrades.
>
> Works quite well.
Hmmm. We're tried this over the last 16 years w/ svr4 packages. Turns
out that trying to invent business processes that prevent people from
breaking the packaging system is incredibly expensive; I'd much rather
fix the packaging system so that it only works correctly.
>
>> 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. Scripting is clearly
broken; it prevents reversible packaging, it needs to be revisited for
each new installation context (eg zones, virtualization), it's a
nightmare in terms of testing, ...
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. It also permits adding
installation contexts w/o editing every packaging script in the
world.
>
>> 3) versioning is undefined
>
> That's like saying, that X11 is broken, because it doesnt tightly define
> [insert GUI system feature here].
> versioning is left open. If sun/whoever, wants to set a versioning standard,
> then SVr4 packaging does not get in the way of that at all.
>
But 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".
>
>> 9) patching is not addressed at all
>
>
> That could actually be an advantange. more below, on patching..
>
>
>> 5) redelivery of a package is required even if one file changes
>
> That's what patching is for. Done RIGHT, that is. Sun does patching...
> poorly. But that's a procedural problem within Sun, imo.
It's not a procedural problem, it's a technology problem. Inventing
more and more baroque patching procedures to compensate for fundamental
defects in the underlying infrastructure is madness.
> Even with IPS, sun is going to have to do the equivalent of "patching", even
> if you put up smoke and mirrors to call it by another name.
> It's still going to suck, if sun doesnt change their back end approach to
> it, rather than just changing the technology front end.
>
> 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
>
>
> Conceptually, I think that's what IPS kind of plans on doing.
> The thing is, you dont have to throw out SVR4 packaging to handle that
> concept.
>
Except that now I have to:
invent pkgupgrade
redeliver 500M of staroffice to fix a one line typo in a doc file
change svr4 package dependencies to include version information
change the dependency code to allow mutually dependent package version
changes.
still solve the zone upgrade issues
still fix the contents file issues
.......
>
> > 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?
> FYI, people have modded pkg-get, to also handle.. *drumroll...* patching.
>
> I just havent had enough time to really evaluate and integrate that code
> myself.
>
>
>> 8) Contents file a huge performance problem
>
> eh... sun was all ready to fix that "problem" with sol10 FCS. Too bad they
> botched it. But apparently, that problem wasnt enough to throw out SVR4
> packaging altogether then, so why should it be now?
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.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
