[gobolinux-users] Re: Problem with CUPS recipe/package

Jonatan Liljedahl lijon at kymatica.com
Tue Aug 16 11:08:16 GMT 2005

On Mon, 15 Aug 2005 22:06:19 -0500
Carlo Calica <ccalica at gmail.com> wrote:

> On 8/15/05, Hisham Muhammad <hisham.hm at gmail.com> wrote:
> > We're doing it this crazy way so that the actual var-files will be
> > under /System/Variable. Reasons: so that can be potentially a
> > separate partition and to allow sharing.
> > 
> > I see at least two problems with our current approach:
> > 
> > - If /Programs/App/Variable already exists during a compilation,
> > previously existing contents will get mixed with new files.
> > - Sharing won't work 100% if some prefixes use
> > /Programs/App/Variable and that does not expose a full view of
> > /System/Variable.
> > 
> > Here's my not-fully-thought-out proposal:
> > 
> > - Programs install to /Programs/App/1.0/Variable.
> > - Var-files are copied to
> > /Programs/App/1.0/Resources/Defaults/Variable.- Var-files are copied
> > to /System/Variable (with some sensible behavior regarding
> > overwriting)- /Programs/App/1.0/Variable is removed, and becomes a
> > symlink to/System/Variable.
> > 
> ** one correction.  It is /Programs/App/Variable.  No version.

Why not?

> I like it, mostly.  First off, deploying files into Variable.  We some
> support with Recipe Resources/Defaults/Variable but I don't think its
> implemented right.  Is that the right mechanism?  If so lets discuss
> how it should work.
> Second, is sharing in Variable really needed though?  If it isn't, I'd
> prefer Variable be symlinks to /S/Variable based on Defaults/Variable.
>  This keeps /P/App/Variable less cluttered and easier to navigate. 
> Conversely, at best /P/App/Variable will never be perfect so sharing
> is much simplier.

Sharing could be needed! Some program may be built of many packages, and
some package may need to read, for example, a pid file from /S/V/run
that belongs to some other package. Also I don't think that
/P/App/Variable should contain any symlinks, I think itself should be a
symlink directly to /S/Variable. That would minimize the problems. It
wouldn't matter if a program writes/reads to /S/Variable or
/P/App/Variable becouse they would be the same. Just like we do with
Shared today... One problem with your approach is that the contents of
/P/App/Variable is locked at install (symlinkprogram) time, as it must
set up symlinks for every file in Variable...

> Revised flow:
>  - Programs install to /Programs/App/Variable.
>  - Var-files are copied to
>  /Programs/App/1.0/Resources/Defaults/Variable.- Copy Recipes's
>  Resources/Defaults/Variable (all of Defaults?) over
> /P/App/1.0/Resources/Defaults/Variable
>  - /P/App/Variable cleared
>  - Recurse /Programs/App/1.0/Resources/Defaults/Variable
>       - Var-files are copied to /System/Variable (with some sensible
> behavior regarding overwriting)
>       - symlink /P/App/Variable to file in /System/Variable
> This keeps the program specific Variable less cluttered.

Isn't this how it works (at least supposed to work) today?

/Jonatan    -=( http://kymatica.com )=-

More information about the gobolinux-users mailing list