[gobolinux-users] Re: Problem with CUPS recipe/package
hisham.hm at gmail.com
Tue Aug 16 17:08:01 GMT 2005
On 8/16/05, Jonatan Liljedahl <lijon at kymatica.com> wrote:
> 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:
> > > 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?
Well, if it's going to just point to /System/Variable, then it doesn't
really makes much difference. I prefer under version because it makes
the versions directory less cluttered, but I would concede to the
backwards compatibility argument. Either way is fine for me. Opinions?
> > 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.
I think Defaults deployed by the Recipe (Settings or Variable) should
overwrite those generated by the compilation. But yeah, I don't know
if it's implemented right (feel free to beat me to it and fix it if it
> > 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...
Agreed. The only problem is cleaning up /S/V, but I don't see to which
extent this is a solvable problem, actually. We're talking about a
writable area, so there is no clear way to know which files were
created by whom and when (simply cleaning up the files the app put
there during installation may not be enough (and sometimes not
wanted), and shared files can't be erased).
I think we have to settle for having a solution for deploying
var-files, but not maintaining them.
> > 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?
Yes, I got the same impression as Jonatan.
More information about the gobolinux-users