Re: More on Kpackage

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Al" == Alex Hudson <eah106 [at] york.ac.uk> writes:

    [Richard sez:]
    >> Just to explain a bit more about the Kpackage bug in SuSE 6.4
    >> that both myself and Craig Andrews have come across.

    Al> Doesn't look like a Kpackage bug to me, I'm afraid!! Looks
    Al> like you have a rpm problem, either a bug in the software
    Al> (unlikely), or a database problem (possible), or a system
    Al> inconsistency (likely).

Agree.

    >> This might suggest that it's just Kpackage ?  But, when I try
    >> to install a GRASS 4.21 rpm (for Red Hat 6.0) I find that I get
    >> "libjpeg.so.6 is needed by by GRASS-4.2.1.i586.rpm".
    >> libjpeg.so.6 is definitely on my hard disk.  I can see it
    >> at.....
    >> 
    >> /usr/lib/libjpeg.so.6
    >> /usr/lib/libjpeg.so.62
    >>
    >> Both Craig and myself have had a look at this and we can't
    >> figure it out.  Even tied all of the RPM options for
    >> installation.

RPM must have a --force-depends (ie, ignore dependency errors) option?
It's really hard to do a mass upgrade without one.

The libjpeg .rpm (you did install via RPM, right? RPM does _not_ go
and look in /usr/lib or /etc/ld.so/cache to see if you have the
library; it checks in its own database for the package) may have been
broken and not properly listing itself in the RPM database.  This
seems unlikely.

GRASS's package may be looking for the "wrong" libjpeg:  it could be a
naming problem (eg, during the glibc switch, Debian had libxyz and
libxyzg packages, the latter being for use with glibc apps), or GRASS
may have a libjpeg-version == 6 instead of libjpeg-version >= 6.  That
may or may not be an error.  Or GRASS or libjpeg might be a libc5 app
(highly unlikely).

Another naming problem might arise if either SUSE or RedHat is
insisting on a specific _package_ version (as opposed to the
application/library version).  No reason whatsoever that RedHat GRASS
can't be looking for libjpeg-6b-27.rpm while SUSE is providing
libjpeg-6b-3.rpm.  The error message you report doesn't seem
consistent with that, though.  Anyway, mixing different distributions'
.rpms is not a good idea (if you can avoid it easily; most of the time
it works fine, so no need to be religious about it).

Get a source RPM and build it yourself, maybe.

vs. Al on .so's:

    Al> What's happening (obviously ;) is that it can't see
    Al> libjpeg. Admission first: I hate libraries. I compile all my
    Al> software statically. I think libraries are the spawn of the
    Al> devil himself [1], and I refuse to use them, have no knowledge
    Al> of how they work, nor do I care about that !!

Boy, you're going to enjoy the 25MB footprint of your new XFree86 4.0!
The rest of us will use the .so-ized drivers, and weigh in at about
1MB ;-)

    Al> But.. I believe you have to have some sort of map or something
    Al> so the system can see stuff? 'ldconfig' or something?

A good .rpm does this automatically.  Furthermore, the package system
doesn't care.

    Al> [1] - I like the idea of libraries. Just, in practice, they're
    Al> crap.  Especially dll's. Awful. IMHO, anything with any

I've had few version dependency problems with Debian, except in cases
where both the app and the library are bleeding edge (and the library
developer goes on vacation and the app developer uploads his
latest-and-greatest to the Debian archive anyway).

And with something like PAM ... I like knowing that fixing a bug in
login means it will also be fixed in ftp ....

    Al> version dependency problems should install to a CVS tree by
    Al> default, and whenever you need a specific version of a

But _which version_?  That's what package managers are for.

    Al> library, you just check it out. But then, I have /home/alex

Why use such a coarse granularity?  You should be talking to the
aetherd people; they think that each variable should have a version.
;-)

    Al> installed to a CVS tree, so perhaps I'm just a VS-nut...

Hey, that gives me an idea.  I don't have /etc/skel/CVS yet, but I
think I need it.  Do you think?  ;-)


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.