gnuplot package fails to install

D

donallen

Doing a # pkg_add -r gnuplot on a newly installed 8.0-release amd64 system results in complaints about missing libpdf.so. The package seems to install, but gnuplot won't run, failing to dynamically load the same shared library. Perhaps I can fix this by building gnuplot myself from the ports collection -- I'm guessing/hoping there's a configuration option for the pdf support that I can turn off, to get a working gnuplot without pdf support. But it would seem that the amd64 gnuplot package is broken, shouldn't be in the release in this condition, and needs fixing.

/Don Allen
 
Code: 
.if ${ARCH} == "amd64" || ${ARCH} == "ia64" || ${ARCH} == "sparc64"
CONFIGURE_ARGS+=--enable-64bit
.endif

Is part of the print/pdflib port Makefile. Best I can recommend is installing it via ports and then trying to add the package again.
 
installing print/pdflib from ports, that is. Then readding the gnuplot package.

pdflib has some bizarre restriction on it's license that keeps a package from being made (according to freshports.org)
 
Ok, thanks, I'll give that a try, most likely tomorrow.

But I'd argue that the package shouldn't leave gnuplot in a broken state. I've seen this issue with the pdf support before with Arch Linux, and I was left with a working gnuplot without the ability to generate .pdf files, a reasonable outcome. I think the FreeBSD package needs to be fixed.

Thanks for your help.
/Don
 
Always happy to help.

When it comes to license issues, FreeBSD's hands are tied. Many Linux distributions don't give a second thought to throwing any old crap into their repositories so that it just works. That's why so many Linux distros were able to do NTFS rw back before the BSDs. They didn't care that it was sketchy :p

If a dependancy can't be packaged for FreeBSD because of it's license, there's going to be dependancy hell :p. It's sad that packages can't be provided as readily as source builds, but to be honest I prefer the way FreeBSD's ports system deals with substandard (or just plain bizarre) licenses. With a bit more ports experience you might come to prefer it yourself.

Although it's hard to break a love of Linux's instant gratification ;)

As a side note, when you've got the time, I'd encourage you to build ports from source, not just use packages. You can really tell the difference between FreeBSD from source and Linux from binaries.
 
Re your comment on ports vs. packages:

This is actually my second go-'round with FreeBSD. I abandoned 7.x because of too many problems with the USB layer (I back up my systems to SATA disks in USB shoeboxes, which regularly killed the 7.x systems; I'm hoping the new USB implementation will be a big improvement). I used OpenBSD for 8 months or so and was very happy with it, though ultimately I'm going to need good SMP performance for the work I'm doing and OpenBSD just isn't up to snuff in that area, which is why I'm back, now that there's a (hopefully) working USB layer.

I mention this to make you aware that

a. I much prefer the BSDs to Linux. Both FreeBSD and OpenBSD have a much more professional, thought-through feel than Linux, which by its nature (kernel by Torvalds, Gnu layer by Stallman, packaging by Arch or whomever, and they don't talk to each other!) is a patchwork quilt. The instant gratification issue isn't a problem here.

b. In my first tour with FreeBSD, I found the port stuff to be a bit of a mess, quite frankly. The issue was the confusing multiplicity of port upgraders (portupdate? portmanager? portmaster?), plus the ease with which you could end up either re-compiling half the system with an ill-considered move with one of them, or get the system into an unusable state. OpenBSD also has a ports system, but they strongly advocate just using packages and foregoing the bleeding edge. My experience with their system suggests that they're right. I ran it with far less drama than I had when I messed with FreeBSD ports. And understand that I'm a just-retired computer professional (I wrote my first computer program in 1960!) and have had a long career in, among other things, OS (kernel) development and managing same. I'm also very familiar with Gentoo and Arch, so I have experience with ports and rolling release schemes (I've had a couple of Arch systems become completely wedged after a full update; they tell you to use "common sense", but I think that's really a warning that their package manager won't keep you out of show-stopping dependency trouble). I'm not a newbie. This is not to say that I won't use ports where necessary (as would seem to be the case in fixing the gnuplot issue), but at this point I think it will only be in such cases.

/Don
 
I also dropped 7.x for the USB layer issues :p recently come back for 8.x and it is looking pretty dang good.

I've not much experience with OpenBSD and it's ports tree but it is fair to say they run it a fair bit more conservatively for security reasons.

I've not played with Arch much (Gentoo was my Linux of choice back when I would choose such a thing), but I didn't feel portage held much water when compared with ports.

You definitely want to stick with ONE port upgrading tool you like, simplifies things a lot. Portmaster is quite popular, but for your purposes, portupgrade would serve you better (it may have a ruby dependancy, but it also has a -PP flag which updates your entire tree from packages where available.)

In my experience (I've just come back for 8.x, but I've run Desktops, and the occassional home server through 4.x, 5.x, 6.x) you get the most from FreeBSD by tracking STABLE and rebuilding your entire tree from source once per month (roughly.) Reading the UPDATING files is a sure fire way to keep from shooting yourself in the foot.

Granted, this does leave you with 1-2 (sometimes as many as 3) days where the machine is impacting performance while you're rebuilding the ports. In this case you can either slow it's haste by using renice, or go out to the movies or read a book (I prefer not to get in FreeBSD's way, although I've never found the build to slow down the system significantly enough to warrant not carrying on as I normally would.)

But YMMV. A much more stable approach is to track RELENG_8 (or update using the FreeBSD binary update utility 'freebsd-update') and rebuild the ports tree only after ever minor version number revision (8.1, 8.2, etc.)

I'm only mentioning how I do it because I feel it's worth the extra time involved. With CPUTYPE set in make.conf, a source build benefits me enough that I'd only benefit myself running packages if I was in a hurry to use the program. Also, there's nothing to stop you from installing and entire system with packages and rebuilding it from source at your leisure (I had a bit of trouble doing this with 8.x, but it was probably my own fault ;).)

It's more or less the difference between a stage1 gentoo and a stage3 gentoo install.

A widespread mixing of packages and ports will shoot you in the foot if you track -STABLE src like I do. But if you do the binary updates or track only the 8.0 tree for major updates and security advisories, you'll not see many problems.
 
Your comment about OpenBSD conservatism is true. Theo de Raadt, who runs that project with an iron fist, to put it mildly, also has very strong ideas about QA and release engineering, which result in an orientation toward things working, rather than being aggressive about the latest version of everything. The resulting system is very, very solid, and also extremely easy to administer (simple config-file setup, very well documented). It's too bad they haven't been able to devote the resources it would take to doing SMP right, as FreeBSD has, especially given that most new hardware today is multiprocessor, because the system they have is much more broadly applicable than the tiny niche (e.g., routers) they currently occupy.

Re Arch and Gentoo: Arch is very nice in many ways. It's a refreshing contrast to the Windows-like bloat of Ubuntu and some other distributions. But, as I mentioned previously, its package manager will not prevent you from wedging your system with version skew. Seems to me that that's the raison d'etre (sorry) for package managers, so if it doesn't do this basic function, what's the point?

Gentoo and Portage are just too damned complicated, in my opinion. I ran it for a couple of years, and spent too much of my life on system administration.

Re your comment on one port upgrader: I figured that one out pretty quickly, but I think there ought to be just one. New users might not figure this out before getting themselves in a world of hurt. I think FreeBSD would be better off by choosing the best one, or combining the best features of each in some sensible way, and offering just one.

Re CPUTYPE: I guess I disagree about the value of compiling for your cpu type. Hardware is so fast now that a few percent is not going to make much of a difference in my life. And that's only in cpu-limited work, which is fairly rare, unless you are doing stuff like image processing. And if you *are* doing work like that and want to eke out the last few percent, you can recompile the application(s) involved (assuming that most of the cpu time is user-mode).

Having said all that, I will save your message and as things diverge from the release, I'll review the techniques you suggest.

I got gnuplot fixed up. Both our approaches work (as I suspected, there is a config option re the pdf support, so turning it off and building the port works; your suggested approach works, too).

Again, thanks for your help and the good discussion.

/Don
 
donallen said:
Re your comment on one port upgrader: I figured that one out pretty quickly, but I think there ought to be just one. New users might not figure this out before getting themselves in a world of hurt. I think FreeBSD would be better off by choosing the best one, or combining the best features of each in some sensible way, and offering just one.
Click to expand...

Tools to upgrade ports are not part of FreeBSD, whcih just offers the core tools (pkg_*, make, etc.). These specific upgrade/maintenance tools all live in the ports tree, and as such they're all third-party software from which a user can make a choice. So there's nothing for FreeBSD to choose and offer as 'best', a practice FreeBSD likes to stay away from anyway.
 
DutchDaemon said:
Tools to upgrade ports are not part of FreeBSD, whcih just offers the core tools (pkg_*, make, etc.). These specific upgrade/maintenance tools all live in the ports tree, and as such they're all third-party software from which a user can make a choice. So there's nothing for FreeBSD to choose and offer as 'best', a practice FreeBSD likes to stay away from anyway.
Click to expand...

I understand your point. But port-upgrading is part of the general package/port/application management system, which feels to the user (certainly this user) like an "official" part of the FreeBSD system, as apt-get is a key part of Debian. Furthermore, the three port-upgrade tools are presented prominently in the FreeBSD Handbook, in a section having similar prominence as the discussion of package management (which you cite as part of the "core" tools). This gives the impression that portmaster et al are as much a part of FreeBSD as pkg_add. If this is not true, then I think the documentation needs more work. The documentation should make clear that these are simply contributed, third-party tools, not "official" parts of the FreeBSD system.

/Don
 
The Handbook clearly states for the three options that you install them like any other port. And as separate ports is the way most FreeBSD users like them. To include any of the three into the base system would annoy users who prefer one of the two alternatives, and more notably add a base program for a package management system that itself has to be installed.

It's pretty much a non-issue. The handbook gives the three options in the order they appeared.

Considering the wide variety of systems run with FreeBSD, they're very particular about what goes into base, and even much of that can be turned off/excluded with the right compile options for embedded or specialty systems.

And in regards to work on the documentation... I don't think Linux has anything remotely comparable to FreeBSD's documentation. In my own experience, it's one of the finest pieces of documentation that exists. I'd put it on par with Dostoevsky, but I liked The Handbook more than Brothers Karamazov.
 
Nirbo said:
The Handbook clearly states for the three options that you install them like any other port. And as separate ports is the way most FreeBSD users like them. To include any of the three into the base system would annoy users who prefer one of the two alternatives, and more notably add a base program for a package management system that itself has to be installed.
Click to expand...

You misread my message. I'm not suggesting that port* be included in the base system. I'm suggesting that the handbook make clear that they are contributed, third-party software (and thus not subject to the same QA standards as the core system). And, if I remember correctly from my previous tour with FreeBSD, you can get into trouble if you mix your usage of them (an experienced FreeBSD user warned me of this; if true, it ought to be in the handbook).

Nirbo said:
It's pretty much a non-issue. The handbook gives the three options in the order they appeared.
Click to expand...

So your point is that they appear in the order in which they appear?

Nirbo said:
Considering the wide variety of systems run with FreeBSD, they're very particular about what goes into base, and even much of that can be turned off/excluded with the right compile options for embedded or specialty systems.
Click to expand...

Again, based on a mis-reading of my post.

Nirbo said:
And in regards to work on the documentation... I don't think Linux has anything remotely comparable to FreeBSD's documentation. In my own experience, it's one of the finest pieces of documentation that exists. I'd put it on par with Dostoevsky, but I liked The Handbook more than Brothers Karamazov.
Click to expand...

Your taste in literature is questionable :stud

I don't know where the Linux v. FreeBSD documentation came from -- I never mentioned Linux documentation. The fact is that I think that the FreeBSD handbook is an excellent piece of work. My reference to the need for improvement was to the section on port upgraders, which was what we were discussing, not to the whole document.
 
donallen said:
You misread my message. I'm not suggesting that port* be included in the base system. I'm suggesting that the handbook make clear that they are contributed, third-party software (and thus not subject to the same QA standards as the core system). And, if I remember correctly from my previous tour with FreeBSD, you can get into trouble if you mix your usage of them (an experienced FreeBSD user warned me of this; if true, it ought to be in the handbook).
Click to expand...

It is made pretty clear by the fact that it's included in the entire Ports sections. If one gets this far in the documentation and doesn't know what a port is, they need to do some re-reading. Not holding third-party (but vital) applications to the same documentation standards as the rest of the system would be problematic, especially with so many GPL/GNU tools originally made for Linux being compilable on FreeBSD. I know the section on X has saved my rear more than once.

donallen said:
So your point is that they appear in the order in which they appear?
Click to expand...

They appear in the order in which they were released. Portupgrade predates portmanager predates portmaster.

donallen said:
Your taste in literature is questionable :stud
Click to expand...

It's a modern academic conceit that technical documentation cannot be considered "literature." Sure, the Russian masters were all very good authors (I do wish they'd shut up about how great Pushkin was for a few minutes though) But in a modern secularist society The FreeBSD Handbook has a lot more to communicate then the subtle precepts of Orthodoxy and why bad people rot faster than the incorruptible.

The Handbook is often also moving in places. Like when root has to shoot his own... aw crap, nevermind, that was Old Yeller.

donallen said:
I don't know where the Linux v. FreeBSD documentation came from -- I never mentioned Linux documentation. The fact is that I think that the FreeBSD handbook is an excellent piece of work. My reference to the need for improvement was to the section on port upgraders, which was what we were discussing, not to the whole document.
Click to expand...

Much of the thread you've been holding FreeBSD up against Arch, Debian, and Gentoo for comparisons. If one assumes every post in every thread in every forum is only of it's own merit, the only ones that make sense are the trolls.

In terms of adding more information to the Handbook... how much is too much? Sure, you could add that you should only use one, although why would you install a second if the first one worked perfectly?

At this point we're just arguing semantics. Everyone and their grandmother (who you think would be included in "everyone") has an opinion on how much information is too much information. Personally I like the handbook's current compilation of "Here are your options. You've got to find the section on fixing crap you break on your own, SUCKERS."

Adding more (in my opinion) would take away from the document as a standing body of work, and quite likely turn it into snippets of information. It's not the FAQ, and the man pages contain more information than both the handbook and the FAQ. It's meant to be read, reflected upon, and then system breaking :p. It's really the only way to learn.
 
I enjoyed your discussion of "literature"; I got a good laugh from it.

I think all of this, at least on my end of the deal, comes from the experience of having used FreeBSD for a time (until I got tired of the system-killing bugs in the ext2 and usb stuff), during which I caused myself a fair amount of trouble with the port upgraders. I then switched to OpenBSD, which I'd still be using if it had real SMP support. OpenBSD is much simpler in many ways than FreeBSD, and their recommended way of using their system is very conservative: install the releases and track STABLE. I won't attempt to completely characterize their approach here, but the net result is a system that Just Works, remarkably stable and easy to administer (I can install OpenBSD on a laptop -- with their text-based installer -- in less than an hour, including WPA wireless).

FreeBSD is not nearly as simple and spare as OpenBSD. Some of that is due to FreeBSD being a more comprehensive system, but I think some of it is a stylistic decision. Going back to the Linux world for a moment, if you love Ubuntu, you aren't likely to be crazy about Arch, and certainly not Slackware. OpenBSD is on the Arch side of the BSD spectrum. FreeBSD is closer to Ubuntu (I say "closer", mind you, not "close"; Ubuntu has become bloatware to me, the Linux equivalent of Windows; I certainly don't feel that way about FreeBSD). So, given that I prefer things as lean and simple as they can be and still do the job, this whole discussion stemmed from what I feel is a bit of a tendency in FreeBSD towards what I view as unnecessary complexity that can cause trouble. This discussion of presenting the user with three alternative ways (that may interact badly) of doing one thing is, for me, an example of this. Obviously, you don't agree. That's fine. I'm simply trying to make you aware of what motivated this whole thing.

/Don
 
You must log in or register to reply here.
Back
Top