On 2004-08-16, MikeyD <m_donaghy50@hotmail.com> wrote:
> Al C. wrote:
>
>> name wrote:
>>
>>>
>>> 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.
>>
>> Here we get to the 'curx' of the matter. What happens if you get some
>> source that requires 'library333' and you only have 'library222'. How will
>> you know? Where (or will?) the error show up? In configure? make?
>
> If configure is written properly, you will get a configure error saying
> something like
> checking for libfoo >=0.94...not found
> ***You need libfoo 0.94 or newer from www.foo.com

This, I think, is where people go into shock. What the hell is that talking
about?

Yep, needs different libraries, so get them. Up to a point.

If every time you try to compile something you find it calling for newer
libraries, you can get that yours are going out of date and you need to
upgrade to a newer distro version. At that point, make a check of the apps
you have compiled that you want to keep, and see if there are newer versions
available. If so, then get the newer versions to recompile when you
upgrade. If not, then copy the old stuff (executables and libraries, etc)
from the old distro before you blow it away.

I guess the point there is to have both the old and the new running in
parallel for a while.

And if the stupid configure routine isn't correct, one can bet that the code
won't be either. Somewhere. Or so I've found.... <sigh>

>>
>> Then.... if you install library333 how to you know you won't break
>> something else?
>
> Because features are never removed from libraries, only added. If it worked
> with the old version it will work with the new version. If the new version
> breaks anything, they will make it a "separate" version you can install
> alongside, like with freetype.

Exactly so.

>> This part of the whole compile form source thing is what is most confusing
>> to noobs... who don't want to screw up their working systems. What is your
>> methodology to keep from breaking things?
>>
> Just do it, a source compile really shouldn't break anything. Or use emerge
> or something.

Do you back up your system? I used to until I found it was easier to start
from scratch, except for the data files, all of which live on another
partition. Keep your local directories separate, with all the libraries on
the local level, of course.

But MikeyD is correct: a source compile, if successful, will break nothing
*if* it's kept on the local level (/usr/local); no conflicts with anything
on the /usr level, which should be only for distro specific apps, I think.
--
Email is wtallman at olypen dot com

> Old Manwrote:

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

Almost. Even if it was compiled against a different version of the
library it might still work.

It all depends on what features the application uses of the given
library. If the compiled binary uses symbols found only in the new
library (or any specific version of that library for that matter), it
will break. This happens often enough you get people recommending you
use the version of the library they built the app around. For all
other cases this shouldn't matter as a
stable library doesn't [i:ffb21e0bbc]normally[/i:ffb21e0bbc] change
the abi. YMMV.

This of course is considering the application was not compiled
statically.

take care,
jason

Message posted via:
=====================
www.linuxpackages.net/forum
www.linuxpackages.net
Expanding the world of Slackware
=====================

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, notbob dared to utter,
>> What is your
>> methodology to keep from breaking things?
>
> RTFM

<modqoute>

A lot of people could stand to learn that.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBIVMZlKR45I6cfKARAlHGAJ9nFILz3tyEOzEPT07jQ2 KQjnsnYACgr2oJ
vmPDy59x/nJEU/ebtxB158Y=
=XtG3
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Jeffrey Froman dared to utter,
> Well, you can cut-and-paste without X by using gpm

s/gpm/screen/

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBIVOtlKR45I6cfKARAmoNAJ0ZmAQKTubrJ1X/90G+mlE2q7+WYACeJsJe
xDJw9vIdRvHosJDgH7C2bZk=
=uIIU
-----END PGP SIGNATURE-----

On 2004-08-17, +Alan Hicks+ <alan@lizella.netWORK> wrote:
>
> In alt.os.linux.slackware, notbob dared to utter,
>>> What is your
>>> methodology to keep from breaking things?
>>
>> RTFM
>
><modqoute>
>
> A lot of people could stand to learn that.

I found a downloadable gftp-2.0.16.tar.bz2 file on the very first page of a
Google search and the lib requirements are given in the very first section
(1.1) of the enclosed README file. If it was any easier, they'd have to
poke out an eye.

nb

+Alan Hicks+ wrote:
>
> In alt.os.linux.slackware, Jeffrey Froman dared to utter,
>> Well, you can cut-and-paste without X by using gpm
>
> s/gpm/screen/

but you're gonna have a mighty hard time c&p-ing with screen from vtX to
vtY... with gpm, you can do that.

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

notbob wrote:

> On 2004-08-17, +Alan Hicks+ <alan@lizella.netWORK> wrote:
>>
>> In alt.os.linux.slackware, notbob dared to utter,
>>>> What is your
>>>> methodology to keep from breaking things?
>>>
>>> RTFM
>>
>><modqoute>
>>
>> A lot of people could stand to learn that.
>
> I found a downloadable gftp-2.0.16.tar.bz2 file on the very first page of a
> Google search and the lib requirements are given in the very first section
> (1.1) of the enclosed README file. If it was any easier, they'd have to
> poke out an eye.
>
> nb

I found a huge number of Google references to the *Slackware package* of
gftp-2.0.16 but when I went to the site(s) all I could find were 2.0.17.
Obviously a lot of Slackware mirrors have not be crawled lately.

While it is moot now, since I got 2.0.17 compiled and running, what site did
you find that actually has a *Slackware package* of 2.0.16 and what search
criteria did you use?

At the time I was NOT looking for source of any of the gftp versions. I didn't
even think about it until someone either here or on Linuxquestions told me to
forget the package and just do the simple (and it IS simple) ./configure,
make, checkinstall from the author's source tarball. First time I had done
that.

Thanks for looking. I'm interested in what site you found with the Slack gftp
2.0.16 pkg. I don't know how I missed it. I really did spend a lot of time
searching.

ANC

On 2004-08-17, Al C. <no.spam.acanton@adams-blake.no.spam.com> wrote:

>> I found a downloadable gftp-2.0.16.tar.bz2 file....

> you find that actually has a *Slackware package* of 2.0.16 and what search
> criteria did you use?

I also did not find a slackpackage, as the file name above indicates. My
reply was more in reference to your question of "what methodology" to
prevent messing things up. All source packages have (or should have) a
README file that provides such info.

> forget the package and just do the simple (and it IS simple) ./configure,
> make, checkinstall....

This has been the unchanging mantra of true slackers long before I ever saw
the light (8.0). Being able to compile from source frees one from all the
tyranny and insanity of all those "this pkg mgr is best" BS. I'm sure your
suspicions that the compiled package worked where the slappy-appy-thingy
didn't are correct, the source properly compiling against 9.1 libs.

> 2.0.16 pkg. I don't know how I missed it. I really did spend a lot of time
> searching.

I did too. When I narrowed it down to a google search of

gftp-2.0.16-i486-1.tgz -current

.....there was zero response. It appears to have disappeared from the face
of the Earth. Even dedicated ftp searches revealed nada. You might have
compiled the 2-16 source using checkinstall. You could have given
it to linuxpackages for others who may encounter your dilemma.

THIS JUST IN:

<http://gd.tuwien.ac.at/opsys/linux/v...table/gui_net/

......note the arch change to i386. Whether or not is works I can't say.

nb

notbob wrote:

> On 2004-08-17, Al C. <no.spam.acanton@adams-blake.no.spam.com> wrote:
>
>>> I found a downloadable gftp-2.0.16.tar.bz2 file....
>
>> you find that actually has a *Slackware package* of 2.0.16 and what search
>> criteria did you use?
>
> I also did not find a slackpackage, as the file name above indicates. My
> reply was more in reference to your question of "what methodology" to
> prevent messing things up. All source packages have (or should have) a
> README file that provides such info.
>
>> forget the package and just do the simple (and it IS simple) ./configure,
>> make, checkinstall....
>
> This has been the unchanging mantra of true slackers long before I ever saw
> the light (8.0). Being able to compile from source frees one from all the
> tyranny and insanity of all those "this pkg mgr is best" BS. I'm sure your
> suspicions that the compiled package worked where the slappy-appy-thingy
> didn't are correct, the source properly compiling against 9.1 libs.
>
>> 2.0.16 pkg. I don't know how I missed it. I really did spend a lot of time
>> searching.
>
> I did too. When I narrowed it down to a google search of
>
> gftp-2.0.16-i486-1.tgz -current
>
> ....there was zero response. It appears to have disappeared from the face
> of the Earth. Even dedicated ftp searches revealed nada. You might have
> compiled the 2-16 source using checkinstall. You could have given
> it to linuxpackages for others who may encounter your dilemma.
>
> THIS JUST IN:
>
> <http://gd.tuwien.ac.at/opsys/linux/v...x-soho-4.0-dev
stable/gui_net/
>
> .....note the arch change to i386. Whether or not is works I can't say.
>
> nb


Well, compiling from source is not always the answer either. gftp 2.0.17 won't
save (upload) an edited file on a remote machine. I've contacted the user
group listserv but have not heard back. I think I will uninstall and drop
back to 2.0.16. I have the source to that.... but maybe I'll try the download
above and see if that works.

Thanks,

Al

Al C. wrote:

>
>
> Well, compiling from source is not always the answer either. gftp 2.0.17
> won't save (upload) an edited file on a remote machine. I've contacted the
> user group listserv but have not heard back. I think I will uninstall and
> drop back to 2.0.16. I have the source to that.... but maybe I'll try the
> download above and see if that works.
>


Update.... I heard from the author... gftp 2.0.17 is broken with respect to
updating edited files. Not a Slack thing. Author has new ver. in his CVS.
Having no time to fool with this. I took the link that notbob dug up and
installed the older 2.0.16 package (after removing 2.0.17). All is well.

I spend a lot of time with FTP and the command line version is too much typing
for these arthritic fingers... and Kong. as a FTP client is OK... but I grew
up with a split-screen client (ws_ftp) so I like gftp. Is there an
alternative anyone else can suggest just for the hell of it? No big deal.
Anyway, thanks, 'nb'.

ANC