[desktop-discuss] Re: Re: Re: Re: Automatic Updates for
Richard L. Hamilton
rlhamil at smart.net
Wed Feb 28 23:17:50 PST 2007
Insofar as those distros are SVR4 pkg based (I suppose some aren't),
provided pkg version dependencies are properly stated in the pkginfo
file, I would think that rather than patches, simple package replacement
(like blastwave does) would suffice for most applications for SX, esp.
since the lifespan of an SX installation isn't intended to be all that long.
For other OpenSolaris distros, it's ultimately their problem, although
in practice, if all needed build info were available, they could either
choose an applicable update package (and repackage it if needed), or
build their own.
That does mean that unless there's a mechanism for delegating the
replacement of packages with other (possibly signed) packages to
at least some more or less normal users, it would take action by the
administrator to actually implement an update. I think that might not
be a bad tradeoff, really: if apps could be configured to simply notify
a configurable email (with some effort to minimize duplicate notifications)
of the availability of security updates. But it should be possible to lock down
at system or software installation level the behavior of such a mechanism,
so that it could be enabled or disabled, and the reporting behavior controlled,
according to site policy. Note that any app that automatically checks for
updates in effect also provides some limited level of usage tracking; some
sites might not wish to subject themselves to that.
For a normal Solaris version, I suppose one would simply check for patches
regularly (daily if one had reason to be that paranoid), at least for any
Sun-supplied software. Heck, for those of my home systems running
Solaris 10 or earlier, I check for patches usually every other day, and
for blastwave package updates at the same time. Security patches or
recommended patches, I'd probably install promptly unless I had a
dedicated test system and some particular testing regimen to apply first.
Others, as needed or as their READMEs seem to suggest they might be
helpful.
For non pkg based software or updates, I suppose it's all up in the air.
In the case of open source software, perhaps working more closely
with the developers (providing them with access to a test system and
some assistance for starters) could get updates for Solaris out faster,
whether directly from them or feeding through Sun (or something
like blastwave) for final testing and packaging. After all, the more
platforms they're tested on, and the more feedback they get, the
more bugs they can kill sooner, and the easier any additional ports
would tend to become.
Build and configuration info should be waay easier to come by for
open source software, IMO; I shouldn't have to spend hours playing
around to replicate someone else's build so that I can move from there
to trying to support additional features or tweak something.
While there are a lot of problems with dependency hell in terms of
having apps coming from all sorts of different places and not being
tested properly together, there are times that the idea of having
build info packaged together with source (like a source rpm maybe)
sounds real good...so I remember http://pkgbuild.sourceforge.net/
and wonder why I'm not finding spec files for firefox, thunderbird,
seamonkey, every darn thing on blastwave, Roland's ksh93 work,
and so on...
This message posted from opensolaris.org
More information about the desktop-discuss
mailing list