May the user set a site-local baseline of package-versions
and freeze that as his "golden" snapshot of packages to
be used by all his machines? Single Packages would get a
up-rev or a down-rev and another refresh of his machines
would deploy them...
I *know* even the enterprise-users will ask us
* Thomas Wagner [2007-10-30 13:39]:
>
> May the user set a site-local baseline of package-versions
> and freeze that as his "golden" snapshot of packages to
> be used by all his machines? Single Packages would get a
> up-rev or a down-rev and another refresh of his machines
> would deploy them...
On Tue, Oct 30, 2007 at 02:39:14PM +0100, Thomas Wagner wrote:
> May the user set a site-local baseline of package-versions
> and freeze that as his "golden" snapshot of packages to
> be used by all his machines? Single Packages would get a
> up-rev or a down-rev and another refresh of his machine
Thanks ... Lukas
Danek Duvall wrote:
> On Thu, Oct 25, 2007 at 04:17:18PM +0200, Lukas Rovensky wrote:
>
>> You are right, I asked about something different and maybe I was just
>> thinking too much the 'patch way'. The scenario I had in mind is like the
>> following -- a customer has a proble
Danek Duvall wrote:
> On Wed, Oct 24, 2007 at 01:28:25PM +0200, Lukas Rovensky wrote:
>
>> 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 co
On Thu, Oct 25, 2007 at 04:17:18PM +0200, Lukas Rovensky wrote:
> You are right, I asked about something different and maybe I was just
> thinking too much the 'patch way'. The scenario I had in mind is like the
> following -- a customer has a problem, a fix is implemented and needs to be
> ve
* Philip Brown [2007-10-24 20:42]:
> Lukas Rovensky wrote:
> > 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.
> > Danek Duva
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 instal
Lukas Rovensky wrote:
> 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.
> .
>
> Thanks,
> Lukas
>
> Danek Duvall wrote:
>> ..
On Wed, Oct 24, 2007 at 01:28:25PM +0200, Lukas Rovensky wrote:
> 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
> pos
Danek Duvall wrote:
>
>> What is pkg_fmri?
>> I checked the man pages in the repo, the slides from the summit, but
>> couldn't make out what the term was meant.
>> smf' already uses the term as "Fault Managed Resource Identifier". Is
>> this term overloaded for pkg?
>>
>
> It's all part of the
On 10/22/07, Stephen Hahn wrote:
> >
> > Yup. wearing my "plain user" hat rather than my "developer" hat, I much
> > prefer typing
> >
> > pkg install foo-devel
> >
> > rather than
> >
> > pkg install foo devel=true
> >
> > It's an existing de facto standard of behaviour, and users are comfortable
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 prob
On Tue, Oct 23, 2007 at 08:21:54AM +0530, S h i v wrote:
> Will the configuration's in a package be query-able, the query
> outputting the configuration options with possible values?
> $ pkg -q foo
That'd be a great addition to the output of pkg info, yes.
> I suppose, the packaging provides for
On 22/10/2007, Danek Duvall wrote:
> > It's an existing de facto standard of behaviour, and users are
> > comfortable with it already. Dare I say, "expect it".
>
> Just because someone's used to something doesn't mean that it's the right
> thing, or that they wouldn't appreciate something better.
Stephen Hahn wrote:
> * Philip Brown [2007-10-22 16:52]:
>>
>> Yup. wearing my "plain user" hat rather than my "developer" hat, I much
>> prefer typing
>>
>> pkg install foo-devel
>[...]
>
> Actually, the default filter settings are part of the image
> configuration. So, if you wanted devel
On Mon, Oct 22, 2007 at 09:51:47AM -0700, Philip Brown wrote:
> Yup. wearing my "plain user" hat rather than my "developer" hat, I much
> prefer typing
>
> pkg install foo-devel
>
> rather than
>
> pkg install foo devel=true
And I think I'd rather specify in the image configuration that I wan
* Philip Brown [2007-10-22 16:52]:
> Joe Di Pol wrote:
> > Danek Duvall wrote:
> >>>...
> >> The way we'd intended to do these was to dump everything into a single
> >> package, tag files appropriately, and use filters to install selectively.
> >> That is,
> >>
> >> file path=usr/lib/libsdl.so
Joe Di Pol wrote:
> Danek Duvall wrote:
>>>...
>> The way we'd intended to do these was to dump everything into a single
>> package, tag files appropriately, and use filters to install selectively.
>> That is,
>>
>> file path=usr/lib/libsdl.so.1
>> file path=usr/lib/libsdl.so devel=true
>>
Hello,
2007/10/20, Danek Duvall :
>
> On Fri, Oct 19, 2007 at 05:19:48PM -0500, Christopher Kampmeier wrote:
>
> > How does this approach relate to the situation where we will have a
> > transportable disk image format for IPS packages?
>
> The fatness of a package in a repo can grow over time as
On Fri, Oct 19, 2007 at 05:19:48PM -0500, Christopher Kampmeier wrote:
> How does this approach relate to the situation where we will have a
> transportable disk image format for IPS packages?
The fatness of a package in a repo can grow over time as more data is added
to it -- new architectures,
Joe Di Pol wrote:
> Danek Duvall wrote:
>>> 3) All subpackages (-devel, -docs, ...) will have only 1 dependency -
>>> parent package. This makes a bit strange order of installing
>>> packages, but I want to somehow mark package that is sub-package.
>>> Cause it doesn't make sense to h
>> 3) All subpackages (-devel, -docs, ...) will have only 1 dependency -
>> parent package. This makes a bit strange order of installing
>> packages, but I want to somehow mark package that is sub-package.
>> Cause it doesn't make sense to have sdl-devel without main sdl
>> packa
Danek Duvall wrote:
>
>> 3) All subpackages (-devel, -docs, ...) will have only 1 dependency -
>> parent package. This makes a bit strange order of installing
>> packages, but I want to somehow mark package that is sub-package.
>> Cause it doesn't make sense to have sdl-devel withou
On Fri, Oct 19, 2007 at 11:08:13AM +0200, Petr Sobotka wrote:
> 2) Prefixes as SFE, OSOL, SUNW will be omitted. But packages will go to
> specified authority - for spec-files-extra I suggest using SFE,
> cause spec-files-extra is quite long and has '-' inside... I think
> that this
Petr Sobotka wrote:
> Hello,
>
> I'm starting to allow pkgbuild outputting IPS binaries.
As you probably are aware, there is no seralized form of an IPS package -
so will your tool create the necessary "pkgsend" operations to create an
IPS repo, or will it actually create the binary IPS repo cont
26 matches
Mail list logo
