Jason Ozolins writes:
Blastwave package upgrade == package remove followed by package install. Not
like, say, RPM's handing of upgrades at all. The service stops while the
upgrade happens. Not to mention, some of our config files got creamed (this
is really the packager's problem rather
James Carlson wrote:
Jason Ozolins writes:
Blastwave package upgrade == package remove followed by package install. Not
like, say, RPM's handing of upgrades at all. The service stops while the
upgrade happens. Not to mention, some of our config files got creamed (this is
really the
Moinak Ghosh writes:
A Solaris upgrade (as opposed to patches) uses packages. The
difference is that the upgrade process uses SVr4 'admin' files when
necessary. Blastwave could do this with instance=overwrite, and
probably should, but it doesn't.
But overwriting with new
Jason Ozolins writes:
Blastwave package upgrade == package remove followed by package install.
Not like, say, RPM's handing of upgrades at all. The service stops while
the upgrade happens. Not to mention, some of our config files got creamed
(this is really the packager's problem rather
Dennis Clarke wrote:
Jason Ozolins writes:
Blastwave package upgrade == package remove followed by package install.
Not like, say, RPM's handing of upgrades at all. The service stops while
the upgrade happens. Not to mention, some of our config files got creamed
(this is really the
Yes; that's what the 'package history' mechanism is about in Solaris
upgrades.
It is more complicated than I suggested, and I think there's likely an
RFE or two buried in here.
In any event, it's not really why we use patches. Patches represent
an atomic change to objects in multiple
Dennis Clarke writes:
So now we have some new binaries, some data files that have not changed,
some binaries that are the same again.
Patch or Package ?
It can be either.
The current method we employ is to remove the whole collection and use the
standards compliant SVR4 tools to achieve
Martin Bochnig writes:
Everyone who thinks he can improve something should go ahead and JOIN
BLASTWAVE.
Or build up his own stack.
Rather than complaining on public lists.
If we can't even discuss the issues on a public list, how exactly do
you propose that we end up working together on
Dennis Clarke writes:
The other issue that arises here is that a patch has a dependency tree also.
If I have a package that requires only a few small changes then a patch
makes sense. If I then make another release with a few more changes then we
have yet another patch. However these patches
James Carlson wrote:
Martin Bochnig writes:
Everyone who thinks he can improve something should go ahead and JOIN
BLASTWAVE.
Or build up his own stack.
Rather than complaining on public lists.
If we can't even discuss the issues on a public list, how exactly do
you propose that we
10 matches
Mail list logo
