[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#261854: xlibs: some softlinks not made correctly, installer fails to upgrade

I'm afraid I do not understand your report.

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?

> 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.

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 (which I hate).

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

> 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.

> for libs I had xlib's /usr/lib/libXft.so and a couple others in /usr/lib


> 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.

What's more correct about /usr/X11R6/lib over /usr/lib?  The Debian Policy
Manual is explicit about this issue:


> 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.

G. Branden Robinson                |     If God had intended for man to go
Debian GNU/Linux                   |     about naked, we would have been
branden@debian.org                 |     born that way.
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature

Reply to: