One more question from the maintenance point of view.  The pkg(1) makes 
possible to freeze a package at a specified version to stop update 
flows.  Currently this is decided by the user to use this constraint. 
Will it be possible to set this constraint in the package itself, that 
is after installing a newer version of the package it will be frozen 
automatically?

Thanks,
Lukas

Danek Duvall wrote:
> On Tue, Oct 23, 2007 at 09:36:12AM +0100, Chris Beal - Solaris Revenue 
> Product Engineering wrote:
> 
>> This is interesting from a maintenance point of view.  Software FRUs have 
>> been something we struggle with for some time. What is the minimum amount 
>> of "stuff" we can deliver to resolve a problem. The package FMRI being the 
>> fault boundary is absolutely the right thing. Would there ever be a case of 
>> faults propagating across a boundary (ie multiple packages needing to be 
>> delivered to resolve and  issue).
> 
> Yes, absolutely.  Fixes to both a service (or other leaf app) and to some
> lower-level component it depends on may need to be delivered together in
> order to fix a particular issue.
> 
> In addition, because of the "no dim sum patching" rule, the supported
> "surface" of the system (the set of package versions defining what's on the
> system) will be limited to configurations tested by the distro vendor, and
> may include a good deal more than just the bits needed to solve the
> problem.
> 
>> I think it is quite likely. Would there ever be a case of delivering only
>> part of a package, as we do with patches now? I would rather we didn't.
> 
> We will always deliver precisely the bits that are needed to move the
> system to the requested surface, and not always all the bits contained in
> the packages affected by that change.  You'll never be able to have a
> partially installed package, though, or one where part of the package is at
> one version level and part is at another.  The surface will always lie on
> package boundaries.
> 
> Danek
> _______________________________________________
> pkg-discuss mailing list
> pkg-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to