Bug#261854: xlibs: some softlinks not made correctly, installer fails to upgrade
Branden Robinson wrote:
I'm afraid I do not understand your report.
Sorry about that! It seems we don't read things the same way. No
problem. script fix_X is less ambiguous.
The NEED for running the fix_X script is that xlib's preinst script
REFUSES to continue installation until fix_X is run (on all of my debian
machines).
However: it's an dist-upgrade script, right? Not a fresh install
script, right? So xlib should not refuse to install on Debian Woody
machines, right? Because all woody machines have the old directory
structure: all machines will fail the directory test.
So I'd say it is critical: all woody dist-upgrades will fail terribly
without advanced user intervention. That is critical by definition,
plain and simple. But I'm not adamant about it.
I made quite a remark below about directory structure and /etc. I
beleive its correct. Don't take it too damn seriously ;)
On Wed, Jul 28, 2004 at 12:01:38PM -0400, John D. Hendrickson wrote:
Package: xlibs
Version: 4.1.0-16
Severity: important
On what grounds do you justify this severity?
After dist-upgrade three differing debian machines all needed fix_X.
Not sure exactly what (dpkg or xlib's preisnt) is at fault. (ie, xlibs:
why not pivot directories before beginning? dpkg: why not remove old X
package files before beginning?)
Two things. One, xlibs did not install files correctly.
"Not correct" is a broad term, and it does not tell me what your
expectations were, or how the package failed to meet them.
never mind
Can you please list all of the files you assert it installed "wrongly", and
explain how? For each file, please indicate:
1) was the file installed to the expected location
2) was the file installed at all
3) was the file corrupt upon being unpacked
Two, all X packages now require a new directory structure
Don't you get it? While /etc/X11/proxymgr has a reason for being in
/etc, /etc/X11/fonts has no reason for being in /etc. That should be
obvious. That is why the origional developers so carfully arranged it
that way. But let me explain it.
1) Reading Sun or Debian installer manual for partitioning, one sees
that the root disk partition should be of minimal size. Piling files in
/etc breaks the root disk concept.
2) Many other packages (like kde, scrollkeeper, xshipwars, ...) now
assume /etc is some kind of free for all config directory - which by
design it is not. Application files should go in /usr/, /opt/, or
/usr/share/. Not in /etc "root system", which is intended for small
critical files needed for booting.
With these apps I've had to go making soft links to move tons of things
out of /etc.
Think of it this way: the question is: what do I need to boot my system
in SINGLE USER mode? That is a root partition.
So YOU are saying, to boot unix I need 256MB of /etc files which
includes configs for childish games?
YOU must be. Since I have to go manually separating games from system
files in order to use the /etc for my system for use in booting my unix
- the unix that I have installed. Get it? Booting unix. Not any unix:
the one installed.
Critical to the idea is: there's a difference between what I need to
boot and what I can do after I've booted. For example: I might need NFS
to mount my root partition. But I don't need /usr mounted to boot. Get
it? I definitely don't need game configs to boot. These should be in
/usr - which doesn't even need to be mounted to boot.
Now think of this. Assume I'm designing a set of X Dummy Terminals
based on a curren version of Linux. Where do I find the essential boot
files I'll need to put in ROM memory for the diskless terminal? /etc?
No. Because some goober has put xshipwars and crap there and I don't
have a 300MB rom! 4MB yes! So I cannot make a Linux X Terminal: not
without redesigning a new Linux boot procedure from scratch.
And also: I couldn't make a root disk. This is a damn shame becasue
they are so usefull. With a root disk you can unmount your usr
partition for maintenance (and do other partitioning tasks) WITHOUT
REBOOTING. A great admin advantage. A great time saver.
So its a shame to see what had been a minimal and trim /etc become a
bloated hodge podge of silly game files, don't you agree?
I'll admit there is some question for X. An X Terminal may need font to
boot.
But as far as I'm concerned the bloat in /etc/X11 itself (including, ie,
sawmill files) is "xlib" maintainers duty: since it is xlib's directory
to begin with: xlib should be aware of issues and inform other packagers
not to use /etc/X11 for "just anything".
I'm afraid I do not understand what you mean here. What directory
structure are you referring to?
Anyway the installer does nothing to provide this new directory
structure.
What installer? Debian-installer? The woody (Debian 3.0) boot-floppies?
I note your bug report is against the (non-security-updated) woody packages
of xlibs.
I should therefore take this opportunity to point out that your stable
system is missing security updates, which I urge you to install as soon as
possible. Please see <URL: http://security.debian.org/ > for more
information.
I made a script which does this which has done this for me on several
machines.
Could you send this bug report the script, or tell us what it does?
Just did a "dist-upgrade" to sarge
Okay. The dist-upgrade does not appear to have completed, as the version
of xlibs you're reporting this bug against is not a version that has been
in sarge for a very long time.
Oops. I filed the report from a server running Woody not sarge. Sorry.
for libs I had xlib's /usr/lib/libXft.so and a couple others in /usr/lib
Okay.
These are xlibs, not usr libs, they shouldn't even have links into /usr/lib
I don't understand your assertion. What's your definition of an "xlib"?
After remaking the links the installer goofed, it worked. Somehow the
installer doesn't take into account the present / previous state when making
its links.
You have lost me here. The only previous state the installer encounters is
either erased or not relevant. Perhaps I do not understand what you mean
by "installer". In Debian, when we say "installer", we mean "the tool the
makes a Debian system from scratch on your computer". I.e., either you
didn't have Debian on the system at all previously; you're abandoning a
previous Debian installation in favor of a fresh installation, discarding
the previous one; or you're installing multiple parallel installations of
Debian to the same computer (rare).
I found the ONLY reason libXft need to be in /usr/lib is due to gtk.
libXft is in /usr/lib because:
1) It is a library;
2) It is not needed at boot time. If it were, it would go in /lib.
3) It is maintained separately from the the X Window System. Xft is an
interesting case due to political and technological reasons. Either
/usr/lib or /usr/X11R6/lib would have been a valid choice at the time
woody was released. Presently, /usr/lib is the right choice, as we no
longer build the current version of libXft from the XFree86 package, but
instead from its own source package, called "xft".
While all else of gnome correctly uses X11R6/lib, gtk uses /usr/lib,
oddly.
Yea. Had quite a talk (about libXft being in /usr/lib though the X
release had it in /usr/X11R6/lib) with someone else.
Turns out a GTK coder, a RedHat employee, did this. He didn't use XLIBS
for the library linkage path: he hacked in a string "/usr/lib/libXft": a
completely weird thing to do.
I consider that a botched job. They had "issues" or something: but
basically they didn't resolve those issues to a typical "unix" degree.
I've seen other bugs in other bug databases which had been causes by the
same issue: the conflict about libXft being in two places at the same
time (which causes can many smaller problems, like broken links), due to
redhat's "solution".
It's still that way! If you compile X yourself libXft goes in
/usr/X11R6/lib. HOWEVER! If you didn't realize /usr/lib/libXft existed
- you might be getting screwed by ldconfig serviing you the wrong lib.
If you installed a "packagers" version you'd then have two libXft's.
---> If you delete /usr/lib... have you removed the OLD or NEW libXft?
Some packagers swear now that libXft belongs in /usr/lib, not
/usr/X11R6/lib - though XFree86 or X.org say /usr/X11R6/lib in all
current releases. Weird.
The problems of having libXft in TWO places (due to package differing
and GTK's static linking needing at least a link in /usr/lib) go on and
on...
What's more correct about /usr/X11R6/lib over /usr/lib? The Debian Policy
Manual is explicit about this issue:
http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.7
Fix that and you fix allot of confusion.
What's confusing about having shared libraries in several different places
on the system? Alternatively, what's uniquely confusing about xlibs or
libxft in this regard? Unix systems have been coping with both /lib and
/usr/lib since well before I became a Unix user over ten years ago.
The ./configure for gtk is just flat wrong. And using ./configure
--prefix=PATH won't help - becuase it is really wrong - a goof up.
It sounds to me like you are reporting a bug in one of our GTK+ library
packages. Nothing I do with libxft or xlibs can fix a bug in GTK+.
To reiterate, I do not understand the nature of your problem report; you
seem to have several related complaints.
I might be able to understand better if, for each problem you perceive:
1) state in specific terms what you expect the package's behavior to be
2) indicate specifically how the package failed to meet those expectations
Please don't use terms like "not correct" or "wrong"; we're still in the
fact-gathering stage of this problem report, not the assessment phase.
Prematurely evaluating the situation will not help us to reach a
satisfactory conclusion.
Thanks for your time.
Thanks for your time!
John D. Hendrickson
jdh@hend.net
#!/bin/sh
cd /etc/X11
x="/usr/X11R6/lib/X11"
xb="/usr/X11/lib/X11"
xx="/etc/X11"
cd $xx/
for z in mwm fvwm fvwm95 xkb app-defaults fs lbxproxy proxymngr rstart twm xdm xinit xkb xserver xsm ; do
echo -ne "$z in /etc/X11 ?"
if [ -L "$z" ] ; then
echo "pivoted"
rm "$xx/$z"
mv "$x/$z/" "$xx/"
ln -s "$xx/$z" "$x"
fi
if [ ! -L "$x/$z" ] ; then
echo " and copied"
if cp -ar "$x/$z/" "$xx/$z/" ; then
rm -r "$x/$z/"
ln -s "$xx/$z" "$x"
fi
fi
if [ -L "$x/$z" ] ; then
rm "$x/$z"
ln -s "$xx/$z" "$x"
fi
echo ""
done
cd $xx/
for z in /etc/X11/* ; do
if [ -L "$z" ] ; then
X="$(dirname "$(find $z -type l -printf "%l")")"
echo -ne "$z on to old X11 ? ..."
if [ c"$X" == c"$xb" ] ; then
echo "rewrite ln"
rm "$z"
ln -s "$x/$(basename $z)" .
fi
echo ""
fi
done
Reply to: