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 en
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 patche
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 a
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 achi
>
> 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 mul
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 packa
> 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 r
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 w
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 pack
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 rath
10 matches
Mail list logo
