On Thu, Jul 27, 2000 at 04:15:59AM -0700, Joey Hess wrote:
> Hmm. What bogus information will dpkg have?
[...]
> I can only identify two problems:
>
> * dpkg -S /etc/X11/app-defaults/foo will fail.
That's what I was thinking of.
> * If some other package also contains an app-defaults file named foo,
> but puts in in /etc/X11/app-defaults/foo, strange things could happen
> if both packages are installed.
Well, that's an ordinary package conflict. Two packages should not be
shipping app-defaults files with the same name unless they conflict.
> Note that both problems can happen even if we adopt your proposed policy
> and everyone follows it to the letter, in the following situation:
>
> * I upgrade to woody, new X, and upgrade all the app-defaults-containing
> packages.
> * I then decide I like potato's version of one of those packages better,
> and downgrade to it. Nothing prevents me from doing this after all.
Hrm. Well, I was kinda hoping no one would do this. A little unrealistic,
perhaps.
> I also have a bit of an alternate idea, which goes like this. You
> mention a few things:
[...]
> Ok, so all packages that have app-defaults files link to the X
> libraries. I assume one of those libraries is responsible for reading
> the app-defaults file[1]. And some horrible thing you haven't specified will
> happen if an app cannot read its app-defaults file.
Some programs, like the new xf86cfg, don't work at all (it just crashes
back to the prompt). xterm staggers a bit but is usable. xcalc doesn't
know how to place its widgets. If this breaks stuff even in other parts of
the XFree86 distribution, I have pretty dire expectations about third-party
clients.
> So, why not hack X[2]? Make the library look in /etc/X11/app-defaults, then
> in the old location. Make policy that states that packages depending on the
> X 4 version of that library should use /etc/X11/app-defaults. Such a
> package would break if it were installed onto a system with an older
> xlib, but the dependancy will prevent that. Upgrades and downgrades will
> work without any messy difficulties. You can remove the xlib hack in a
> release or two.
I was hoping to avoid this, but developing consensus on -policy seems to be
that I should do this. Sigh.
> [1] Verified, that is lib/Xt/Initialize.c, XtScreenDatabase()
I'm not sure it's not the only one. It's not just Xt-using apps that read
app-defaults, IIRC. I think the Xrm* functions may deal with it as well.
I'll check this out.
> [2] And yeah I looked at the code and it looks doable. Insert a check for
> a file in the old directory around line 534 of the file in [1].
Thanks.
--
G. Branden Robinson | You live and learn.
Debian GNU/Linux | Or you don't live long.
[EMAIL PROTECTED] | -- Robert Heinlein
http://www.debian.org/~branden/ |
PGP signature
