Solved [SOLVED] Best Practice for new installations two questions

Good Afternoon all,

FreeBSD 10.0 x64.

I have been on FreeBSD for about a couple of weeks now, with 4 previous weeks on a separate drive.

I am about to schedule a changeout of my first client server from CentOS to FreeBSD 10.0.

On my system, I use the pkg install <packagename> paradigm. Then for those things that pkg tells me doesn't exist (like VirtualBox), I then build it from the ports tree.

So on my system, and on my client's systems, it apprears that I will need a mix of binary and ports built packages. I see there is quite the process to updating installed ports after refreshing the ports tree, or upgrading to a new FreeBSD release. Update from pkg is a piece of cake.

My questions are:

a) Is mixing software from ports and binary repos considered bad form? I want to deploy on my clients' machines using best practices.

b) Upgrading the ports tree is childish simple. In the official handbook, upgrading the ports that have been built and installed seems overly involved, complicated, and labor intensive. Is there some easier, or more straightforward mechanism of rebuilding/upgrading the installed ports packages after updating the ports tree?


Would someone more experienced than me in FreeBSD 10.0 provide some insight,... please?


I will be appreciative for assistance and the experience of others,


Sincerely and respectfully,


Dave
 
Re: Best Practice for new installations two questions

We've seen lately that mixing the two methods of installing software and avoiding problems is non-trivial.

What upgrade procedures are you using? Here is what I suggest: Upgrading FreeBSD Ports.

If the pre-built binary packages do not have the options you want, consider setting up Poudriere to build your own binary packages. That lets you build custom packages on a single machine, which can be installed on multiple machines. There is a new, short section on Pourdriere in the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-poudriere.html. There is at least one article here in the HowTos forum also.
 
Re: Best Practice for new installations two questions

Thank you for the articles.....I thik I should just check out your whole website. It has been full of good procedures since I discovered it.

I would like to ask one further request for clarification before I mark this thread as solved:
wblock@ said:
We've seen lately that mixing the two methods of installing software and avoiding problems is non-trivial.

I am interpreting this as mixing ports and binaries as a very bad idea. Am I understanding things correctly?

Thanks for the clarification,


Sincerly and respectfully,


Dave
 
Re: Best Practice for new installations two questions

dcbdbis said:
a) Is mixing software from ports and binary repos considered bad form? I want to deploy on my clients' machines using best practices.
I'd say it heavily depends on how the machine is going to be used and maintained as well as on how you installed the software.

For example; if you installed everything while not making any changes to the configuration then the mixture should work just fine. But if you change options, specifically if you disable certain options, then that could cause problems when you install a binary package later on which depends on those options to be in place.

From what I read in this thread pkgng has some fail saves for that; when it detects that a package's configuration is different it will automatically re-install that package so that the required options will be put in place.

Yet that could become a new problem if enabling such an option would also require that new / other packages are being installed. Especially if one package conflicts with the other. I can't think of any solid examples, but I can well imagine that this could happen.

So I'd say it heavily depends on how you're going to use the system.
 
Re: Best Practice for new installations two questions

Here is how I built my first workstation:

a) I installed per the wiki. No exceptions taken, no configurations modified.

b) Wanted to stick with the pkg paradigm, but things like VirtualBox were reported by pkg as not being part of the binary repos.

c) I built VirtualBox from source becuase I needed it. Though VirtualBox appears in the binary repos, pkg can't find it.

d) I built some custom kernels removing the stuff I didn't need, but left the kernel build configuration alone so that all the modules would be built at the same time. This way if I needed some extra functionality in the future, I could just kldload it.

I would stick with the binary packages so I would have a "mono" system, but not all the packages I needed were available in the binary repos, well, at least according to pkg.


So now you know how I have deployed so far.....Would you consider this "safe" to mix source and binary?



Thank You!


Sincerely and respectfully,

Dave


PS: In many cases I find wblocks documentation much easier to absorb, understand, and follow than the handbook. Ref: http://www.wonkity.com/~wblock/docs/index.html
His article on SSD's has been tremendously helpful.
 
Re: Best Practice for new installations two questions

@@ShelLuser
I just wanted to say, that I think you articulated the difference perfectly. That's exactly the difference. :)

Best wishes.

--Chris
 
Last edited by a moderator:
Re: Best Practice for new installations two questions

I think many of us have benefited from @wblock's well written and easy to follow articles.

As for mixing packages and ports, I think that while I have seen some disasters on these forums, I've personally only had a few minor hiccups. (To me, anyway). For example, installing x11-servers/xorg-server by port, because I wanted to use the new xorg, then installing the mouse and keyboard driver by package. When I started X, neither mouse nor keyboard worked, and if I remember the message correctly, it was something about a module or version mismatch. I then ran pkg delete -f for both, reinstalled from ports, (and both install very quickly) and all was fine. However, I continued to install other packages that take a long time to compile, such as editors/libreoffice www/firefox and probably a few others without problems.
So--for my personal needs--I haven't (yet) run into major issues, just minor inconveniences.

Just in case you're not aware of it, there's a port known as ports-mgmt/psearch that can be handy for finding out the correct name of a package. The pkg search -i will do a case insensitive search for a package name. I'm not sure if there's a package for emulators/virtualbox-ose or not, but when running pkg install you do have to get the name right--so if you tried pkg install VirtualBox it would definitely fail.

Testing on a FreeBSD-10 installation, running pkg search -i virtualbox shows me that it is available as a package. However, running pkg search VirtualBox gives back nothing. It's always useful to add the -i, for case insensitve, option.
 
Last edited by a moderator:
Re: Best Practice for new installations two questions

If the client machines all will work with stock packages, use those. The clients likely won't have VirtualBox anyway. Right now, ports are the only way to get the KMS video drivers. The default is planned to change in the next month, and then (I think) the X video drivers in the packages will be the KMS version.

If you need custom packages, Poudriere is probably the easiest way to get there. On the Poudriere build machine, it builds those packages from ports, the ones you want and with your custom settings. Each of the client machines uses that build machine as a repository, installing the custom binary packages from it.
 
Re: Best Practice for new installations two questions

Thanks for the comments on my articles. We (the documentation team) are also working on improving the Handbook and other documents.
 
Re: Best Practice for new installations two questions

I thank all for the input....

For now, I only need VirtualBox-OSE from ports. All else that I need is available as binaries.

So I will be pure binary except VirtualBox. That won't be too tough to handle at all.......

When the KMX stuff comes out, it will be easy to make deinstall and then install the binary with the KMS stuff built in it.


Thank you once again for all,


I'm going to mark the topic as solved.


Sincerely and respectfully,


Dave.
 
Re: Best Practice for new installations two questions

I know it's in the details, I can't help myself here ;)

dcbdbis said:
When the KMX stuff comes out, it will be easy to make deinstall and then install the binary with the KMS stuff built in it.
Just for the record; keep in mind that once a port is installed it's basically become a package. So although # make deinstall will work perfectly you could just as well run # pkg_delete -x pack (for old times sake, ok? ;)) or the modern variant: # pkg delete -x pack. (where pack is obviously part of the package or port name).

And I'm glad that you now managed to solve your problem. Hope your client will end up happy too!

(as a small (offtopic) side note (probably mini-rant): this is why this "FreeBSD project" rocks in my opinion. Do you notice how the only difference between those two commands is a mere _ character? Easily said, easily observed, but setting the whole thing up... that's the real challenge).
 
Re: [SOLVED] Best Practice for new installations two questio

Thank you ShelLuser,

I didn't know that you could use pkg delete to remove a port. That's great to know!

May I also ask...will pkg autoremove then remove the dependencies as well?
Of course assuming that they are no longer needed by anything else.


Thank you!


Sincerely and respectfully,


Dave
 
Re: [SOLVED] Best Practice for new installations two questio

pkg autoremove removes every single package that is not needed in the system anymore. This includes deprecated packages that are not required anymore as runtime dependencies, as well as all the dependencies of any package that has been deleted from the system by the sysadmin.

Just try it and see for yourself. All commands ask for confirmation anyway. And most of them - pkg autoremove included - also provide a "dry-run mode" option (-n).
 
Re: [SOLVED] Best Practice for new installations two questio

Beastie said:
pkg autoremove removes every single package that is not needed in the system anymore.

Technically, packages that were installed as dependencies but are no longer depended on by anything.

So if you manually install a port or package, that should not be removed by pkg-autoremove.
 
Re: [SOLVED] Best Practice for new installations two questio

Thanks...but to clarify....

If I remove a package installed with ports...and the port brought down with it a bunch of dependencies that are no longer needed....will pkg autoremove hopefully get rid of the un-needed dependencies that the original and deleted port brought down with it?


Again, I thank you.


Sincerely and respectfully,


Dave
 
Re: [SOLVED] Best Practice for new installations two questio

Remember that once installed, a package and a port are the same thing. So yes, pkg autoremove should still work correctly. Untested by me, though.
 
Re: [SOLVED] Best Practice for new installations two questio

Roger that,

Thank you for the clarification......I didn't know it in those terms, and that is what I was after. In my head I was keeping ports and packages as separate entities....And was going to go down the older make deinstall after changing into the dir of the original port.

I must say this....As a user of Arch Linux since 2004, I find FreeBSD's pkg package manager to be easier to understand, and have more mainstream functionality than Arch Linux's pacman. And I considered the latter as a good package manager and still do. It's just that pkg has so much more functionality that is practical, and easier to understand. The pkg autoremove command (I've already used it) is more accurate than ArchLinux's counterpart. That's a job well done.

Whoever's brain child the pkg paradigm is/was...deserves a "well done" pat on the back. It's really that good.....


Sincerely and respectfully,


Dave
 
Back
Top