PBI and ports/packages

[nesredep]

Forgive me if this is a lame question. I went to the knowledgebase and clicked PBI tutorial on the very top, but it's a broken link.

As for my question:

I come from the Linux world. I have tried FreeBSD, DesktopBSD, and PCBSD, multiple times, on different machines.

I like PCBSD the best; the basic install configuration easily gives me (Nvidia drivers, compiz, stuff like that).

But I have problems with the PBI thing. I've been reading a lot of discussion (debate!) about it.

(Ooops, I now realize that my question is multi-part)

If I install PC-BSD from scratch, and I DO NOT install any of the applications offered during the install, will I then have a totally PBI-free installation? I could portsnap fetch/extract and use pkg_add to install applications, right?

I have gotten the impression that mixing PBI with ports and packages is where I have had trouble. Is there a total twenty-foot wall that partitions the PBI from the ports/packages system? So if I tried a PBI and then wanted to get rid of it (for example if a new version of the application was available on ports), is it easy to do? Or does the PBI reach into the ports/packages for any dependencies? Or vice versa?

Sorry, these are dumb questions, but I've done so much reading about FreeBSD and its cousins, my mind is overloading.

John

[TerryP]

If you install PC-BSD and do not install any of th e PBI included on CD#2, you will have a PBI Free installation. -> Some of the software included on CD2 is in PBI's the others are FreeBSD packages, and ports and src are just tarballs.

You can look at CD2 before install (or during if you have a second disk drive) and look through it and note the .pbi files. Normally I install any of the kde* collections I want from CD2 because they are done with FreeBSD packages.



The main reason why intermixing ports/pkg and PBI is such shit, is because of how Unix and CP/M derived (and probably most other modern) Operating Systems work at the CLI level.

If I type linux-flock into my shell prompt, it looks to see if it is a built in command and if it is not, it checks into my $PATH, on DOS/Windows based systems COMMAND.COM/CMD.EXE would look at %PATH%.


linux-flock is a shell script in /usr/local/bin/ that runs the browser out of it's installed location in /compat/linux/*. But the OS Shell looks in /bin, /sbin, /usr/bin, /usr/sbin, and then finds it in /usr/local/bin.

It does not know to look into /compat/linux /Programs/FlockX.Y.Z./bin/flock because they are not in my $PATH and if they were would have to come before /usr/local/bin/.


The system was designed contrary to that method of software installation, because it looks for communal directories of software not /Somewhere/ProgramVersion/. Windows NT works exactly the same way -- only the GUI hides this, just like PBI do when you use the KMenu or Icons to launch the PBI file on PC-BSD, same thing.


Depending on the software version used to create the PBI file and on the PBI Developer, they may wish to place files (via symbolic link) into the system, like /usr/local/bin/flock and friends so I can run the program without having to launch it through what they provide (rarely done these days).


Further more, unless they have properly configured and built the program used in the PBI (in this analogy, flock). The program may require access to files in /usr/local/share/ or other directories in /usr/local/ depending on the program. If they are not there, the program won't run correctly without 'tweaking' during the PBI's creation.


Now if /usr/local/bin/flock exists and is a symbolic link to the PBI's script. If I installed www/flock from ports, it would fail to install after compiling because /usr/local/bin/flock already exists.

All the worse, if the PBI was un installed and left files behind (like /usr/local/bin/flock) it would still break. And if the FreeBSD port was poorly made.... It might install any way and overwrite the file(s) from the PBI file! Thus complicating things further.


Also if I was to install a port that depended on Flock, but only had Flock installed by PBI; because of the dependency handling of the FreeBSD ports/pkg subsystems (unlike some old solutions on Linux, e.g. old school Slackware). The port (or pkg of) www/flock would have to be installed as a prerequisite.


Maybe if PC-BSD had a script to kill all dependency tracking in ports/pkg and a special /bin/sh compatible program to 'patch' the design problem of how $PATH works it might be different but....


It all just gets to be a pile of steaming buffalo pucky...



NOTE: That I am ONLY using the Flock PBI and Port as examples and in no way intend to say that either are poorly done.

[nesredep]

If you install PC-BSD and do not install any of th e PBI included on CD#2, you will have a PBI Free installation. -> Some of the software included on CD2 is in PBI's the others are FreeBSD packages, and ports and src are just tarballs.

You can look at CD2 before install (or during if you have a second disk drive) and look through it and note the .pbi files. Normally I install any of the kde* collections I want from CD2 because they are done with FreeBSD packages.

The main reason why intermixing ports/pkg and PBI<snip>

Thanks! So I conclude: if a person wants a nicely configured FreeBSD system with a KDE face, PCBSD is a good way to go, only don't install any PBI apps.

From my reading, I get the sense that PBI is a really good idea, in concept. If only it was completely segregated from the well-established ports/package. I guess that would call for independent naming, so that path conflicts don't arise.

Way over my head, but I hope they work it out. I find that I like *BSD slightly better than Linux, and that means I need to get something relatively trouble-free NOW, not six or twelve months from now.

Thanks for the detailed reply--most helpful!

John

[nesredep]

Ooops, one more thing, re: PBI-free installation.

If one installs 1.41, and then updates with the 1.411 PBI, is that harmless enough?

John

[TerryP]

Yeah... We have a lot of long-wind for words in my family :\

PBI done properly are self contained but I think it needs to be done 'just so' to get it worked out properly, in order to make PBI work smoothly, and ports/pkg to work smoothly... It is not really that hard but who listens to me?


It is possible to have both PBI and Ports/Pkg on the same system, even stuff installed manually (the ol'src tarball way). You've just got to be a bit selective because any conflicts, you've got to manage your self because of the 2 different sub-systems.


The reason I chose BSD over Linux, was a matter of taste... Taste for design and engineering over a distro of pieces :-)



Installing the PC-BSD Update PBI's shouldn't frag any thing other then what they update, which is generally what you get from CD1. So I wouldn't worry about that unless you are prone to losing power during a patch-install. Using the CD's upgrade feature... Last time I used it it removed every thing in /usr/local/* but I hear it's been fixed, back ups are always good.


Before installing, I normally take a backup of my /etc/, /boot/, and any thing that I had to manually adjust from the base install, just in case it get's overwritten. Unless of course I get to test it on another machine first hehe but hey, I am a little paranoid =/