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. branden@debian.org | -- Robert Heinlein http://www.debian.org/~branden/ |
Attachment:
pgpb0T0kkNPTZ.pgp
Description: PGP signature