I write this for other noobs and semi-noobs (like me) so they/we might get a
better understanding of packages in Slack... and in the hope that some kind
soul will correct this if it's WRONG! And there is a question or two in here
also.

I use the example I just had with gftp (a nice GUI FTP program.)

Slack 9.1 came with gftp version 2.0.15 (I'll call it gftp-15). At that time
9.1 was 'current'. But there was a problem. gftp-15 was broken (you could not
rename a remote file). The author realized this and quickly brought out
gftp-16 and (both?) the Slack site and Linuxpackages made a package and
carried it in the 9.1 (current) listing (on both sites). Folks like me did an
upgradepkg and it worked great. We're happy little clams.

Along comes 10.0 and at the same time comes gftp-17. This package is made and
is shipped with 10.0 (which is now 'current').

A problem occurs with a 9.1 user. By accident, when playing with slapt-get she
upgrades to gftp-17 that she gets from 'current'. It does not work. Why? My
guess (please someone corroborate) is that it was compiled using a different
library or widget that is in 10 but not in 9.1????).

OK, not to worry. She goes back to the Slack or Linuxpackages site to get the
gftp-16. Ah, but it is not there. gftp-15 is there because that's what came
with original 9.1 and Patrick, of course, keeps it around. But the gftp-16 is
nowhere to be found anywhere... because it's not 'current'. Only the the new
gftp-17 version is there... which won't work on 9.1.

You ask, why didn't she keep the .tgz package of gftp-16? Because she figured
she could always download it from the Slack site again. Wrong! So she has to
load the gftp-15 'broken' package. She does. It works... but is still flawed
(obviously) and she is not a happy clam.

Then she comes here or Linuxquestions and is told "Hey sweetie, just get the
source and compile it. So she follows the directions, untars the download, as
a user does ./configure and then make. She then su's to root and does
checkinstall... and WHAM she has gftp-17 automagically installed and it works
great. She's back to being a happy clam.

Question: What actually happend when she did the ./configure, make,
checkinstall? Did Slackware compile the program using her 9.1 libs? If
gftp-17 requires updated libs that 9.1 does not have, how come it works?

Anyway, the moral of the story is that you should always save any packages
that you download... because you might need them again if you are not running
the current version. Just because they are on the Slack site now, does NOT
mean they will be later on.

All's well that ends well... but it would be nice if the Slackware site
archived the 'highest number' package that worked with each version of the OS
so that people not running the latest version of Slack would not have to
compile/make (although to be honest it was pretty simple.) I believe the RMM
'find' sites do something like this. And I guess the other moral of the story
is that when a new ver of Slack comes out you can save yourself some trouble
by upgrading to it.

I hope this helps someone on this quiet Sunday morning. I know it puts things
in perspective for me. And while I still lobby for an 'official'
blessed-by-P.V. dependency-checking pkg mgt. system, what we have now is not
totally terrible... just a bit confusing for the noob. (But that is another
issue.... already beaten to death here.)

Enjoy the day. 8am here in sunny CA. Time for my daily 2 mile run. Screw it.
I'll do it later. I'll mix a bloody mary instead. I got vodka here
somewhere. November was a good month!


ANC

Al C. wrote:

> Along comes 10.0 and at the same time comes gftp-17. This package is made
> and is shipped with 10.0 (which is now 'current').

This part is WRONG! (your caps and exclamation) -- "current" is a different
branch from 10.0, and contains a few different package versions already. As
time goes on, the differences between the two will grow.

Jeffrey

Jeffrey Froman wrote:

> Al C. wrote:
>
>> Along comes 10.0 and at the same time comes gftp-17. This package is made
>> and is shipped with 10.0 (which is now 'current').
>
> This part is WRONG! (your caps and exclamation) -- "current" is a different
> branch from 10.0, and contains a few different package versions already. As
> time goes on, the differences between the two will grow.

Thanks for pointing this out. It might be better if P.V. called the branch
'testing' or 'development.' Might be less confusing to those already
confused!

ANC

Al C. wrote:

> A problem occurs with a 9.1 user. By accident, when playing with slapt-get
> she upgrades to gftp-17 that she gets from 'current'. It does not work.
> Why? My guess (please someone corroborate) is that it was compiled using a
> different library or widget that is in 10 but not in 9.1????).
>

Right. It was compiled against, or linked to, a different set of libraries.

>
> Question: What actually happend when she did the ./configure, make,
> checkinstall? Did Slackware compile the program using her 9.1 libs? If
> gftp-17 requires updated libs that 9.1 does not have, how come it works?
>

Wrong. It does not require the updated libraries (in this case). But it
does require the library versions it was compiled against.

--
Old Man

Al C. wrote:

> Thanks for pointing this out. It might be better if P.V. called the branch
> 'testing' or 'development.' Might be less confusing to those already
> confused!

Don't hold your breath :-) Meanwhile, I've posted a document that attempts
to explain "current" if you're interested. It lives at
http://uselesstree.org/tree/trunk/th...-current_howto

Jeffrey

Al C. wrote:

> Thanks for pointing this out. It might be better if P.V. called the branch
> 'testing' or 'development.' Might be less confusing to those already
> confused!
>
> ANC

P.V. points it out very clearly.

"Slackware-current ChangeLog"

"Intel Architecture"
"(ftp://ftp.slackware.com/pub/slackware/slackware-current/ChangeLog.txt)"

"This is the current development tree for upcoming versions of
Slackware."

As someone once said, "Those who don't read are no better off than those who
can't read." And no amount of re-writing or re-naming will overcome that
obstacle to understanding.

--
Old Man

Al C. wrote:
> Slack 9.1 came with gftp version 2.0.15 (I'll call it gftp-15). At that time
> 9.1 was 'current'.

what do you mean by "current"? the latest official release, or that which
is contained in the directory current on slackware mirrors? if you mean the
latter, your statement is wrong. an official release is never current in
that sense. 'current' contains the ongoing work towards the new version,
and packages in it are not guaranteed to work with the latest official
release.

> A problem occurs with a 9.1 user. By accident, when playing with slapt-get she
> upgrades to gftp-17 that she gets from 'current'. It does not work. Why? My
> guess (please someone corroborate) is that it was compiled using a different
> library or widget that is in 10 but not in 9.1????).

library. a widget is something you can click on in a GUI window.

> Question: What actually happend when she did the ./configure, make,
> checkinstall? Did Slackware compile the program using her 9.1 libs?

yes.

> If
> gftp-17 requires updated libs that 9.1 does not have, how come it works?

gftp-17 (obviously) doesn't require updated libs that 9.1 doesn't have,
otherwise it would not compile. what happens is that the compiler will use
the libraries that are present on the system.

a *binary* (i.e., compiled) version of a program can only run on a system
that has the exact same libs as the system it was compiled on. that's why a
10.0 package won't necessarily run on 9.1: it has different versions of the
libraries.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Jeffrey Froman wrote:

> Al C. wrote:
>
>> Thanks for pointing this out. It might be better if P.V. called the branch
>> 'testing' or 'development.' Might be less confusing to those already
>> confused!
>
> Don't hold your breath :-) Meanwhile, I've posted a document that attempts
> to explain "current" if you're interested. It lives at
> http://uselesstree.org/tree/trunk/the_complete_slacker
slackware-current_howto
>


Jeffrey, The Complete Slacker is really a good piece of work. I bookmarked it
and I hope it gets listed in the FAQ of Slackware oriented sites to visit.
Thanks for your efforts on this. It's appreciated by lots of folks, I'm sure.

ANC

On 2004-08-15, Jeffrey Froman <jeffrey@fro.man> wrote:
> Al C. wrote:
>
>> Thanks for pointing this out. It might be better if P.V. called the branch
>> 'testing' or 'development.' Might be less confusing to those already
>> confused!
>
> Don't hold your breath :-) Meanwhile, I've posted a document that attempts
> to explain "current" if you're interested. It lives at
> http://uselesstree.org/tree/trunk/th...-current_howto
>
> Jeffrey

YES!!!!!! Bookmarked!!

You've got a good explanatory style. Trick, as you apparently know, is to
ferret out any hidden assumptions as you're writing, and somehow gracefully
include same appropriately. Highly commendable!!
--
Email is wtallman at olypen dot com

On 2004-08-15, Joost Kremers <joostkremers@yahoo.com> wrote:
> Al C. wrote:

<snip>
>> If
>> gftp-17 requires updated libs that 9.1 does not have, how come it works?
>
> gftp-17 (obviously) doesn't require updated libs that 9.1 doesn't have,
> otherwise it would not compile. what happens is that the compiler will use
> the libraries that are present on the system.
>
> a *binary* (i.e., compiled) version of a program can only run on a system
> that has the exact same libs as the system it was compiled on. that's why a
> 10.0 package won't necessarily run on 9.1: it has different versions of the
> libraries.
>

Which is why I don't do compiled packages now. I get the source, compile
it, and my /usr/local level can eventually get as large as /usr itself.
Thing is, I keep /usr/local/src on a separate partition, so that if I want
something I might not be able to get later (not on Sourceforge, for
instance), I can recompile for newer libraries. Also tend to keep older
versions of libraries for the same purpose, and have to weed them out
periodically. But unless there are drastic changes, source code can keep on
working for quite a while.
--
Email is wtallman at olypen dot com