Solved Mixing ports and packages question

I read threads about this subject and I understand why it's advisable not to mix ports and packages, but let's assume that the objective is to build and install a window manager without building x11-servers/xorg-server, because the default build options of x11-servers/xorg-server and the default build options of x11-servers/xorg-server dependencies will be used.
Assuming that:
1) Only base system is installed.
2) pkg repository is set to latest.
3) # pkg update
4) # portsnap fetch extract
5) # cd /usr/ports/ports-mgmt/postmaster ; make install clean
6) # cp /usr/local/etc/portmaster.rc.sample /usr/local/etc/portmaster.rc
7) # vi /usr/local/etc/portmaster.rc and I enable these options:
Code:
# Always delete stale distfiles without prompting (-d)
ALWAYS_SCRUB_DISTFILES=dopt
# Be verbose (-v)
PM_VERBOSE=vopt
# Install packages for build-only dependencies (--packages-build)
PM_PACKAGES_BUILD=pmp_build
# Delete build-only dependencies when finished (--delete-build-only)
PM_DEL_BUILD_ONLY=pm_dbo
#Suppress the build confirmation message (--no-confirm)
PM_NO_CONFIRM=pm_no_confirm
8) # pkg install xorg-server
9) The remaining ports are build and installed with portmaster, changing at least one default build option of the window manager.

Here comes my question:
Is it possible to avoid conflict of xorg-server package with the remaining ports?

Thanks in advance!
 
A lot of the warnings against mixing ports and packages are old and outdated. The old pkg_* tools were unable to detect the conflicts caused by mixing ports and packages. The resulting breakage could be very tedious to clean up. These days can start with packages an build a few ports in addition, but it is a fragile path. If you have access to beefy FreeBSD box I would recommend building your own repo with poudriere. Unless you want to customize everything define your options in make.conf to keep things simple and all state in a single place.
 
A lot of the warnings against mixing ports and packages are old and outdated. The old pkg_* tools were unable to detect the conflicts caused by mixing ports and packages.
Wrong, on both accounts.

It has nothing to do with conflicts and all that. In short: the problem is that packages are build against default (build) settings and also expect those default settings from their dependencies. So if you mix ports and packages and somehow end up changing the build settings for a port which is required by a package then you can run into major problems if you end up disabling a setting ("feature") which that package was depending on.
 
These days pkgng has enough metadata about packages to deal with most cases and help you build the reverse dependencies as well or at least fail at install time (look at synth for an example of how that can work).
 
Wrong, on both accounts.

It has nothing to do with conflicts and all that. In short: the problem is that packages are build against default (build) settings and also expect those default settings from their dependencies. So if you mix ports and packages and somehow end up changing the build settings for a port which is required by a package then you can run into major problems if you end up disabling a setting ("feature") which that package was depending on.

Hey! Can you tell me how an experienced problem of this sort would look like? I tend to mix installs from ports and pkg (just a few programs) and so far I have had like no visible problems. The only occurence is if a shared dependency is compiled with another version than the one brought with pkg for another program. In that case that program, say Firefox which shared ffmpeg with audacious-plugins for me, couldn't be started until I got the correct version of Firefox to match the dependencies.

Question: Can I expect an easy troubleshooting like this eveytime it would occur or can I end up with more ugly problems? I would find it very disappealing with a system running on unhealthy settings affecting, say, graphics or cpu in a nightmarish manner.

Thanks!

PS. Can the major problems you speak of occur even if you stick to defaulted port options?
 
Can you tell me how an experienced problem of this sort would look like?
Absentmindedly running pkg upgrade and realizing that your MariaDB 10.1 client is suddenly replaced with the MySQL 5.6 client. Because the official packages use MySQL 5.6 by default and my own installations use MariaDB. Or worse, getting LibreSSL and OpenSSL mixed up. Or Python versions, or Ruby, LUA, PHP and a bunch more. And those are only the obvious ones.

PS. Can the major problems you speak of occur even if you stick to defaulted port options?
No, but then you won't have a reason to build from ports to begin with. There's really nothing to gain by building from ports if you're going to stick to the default options.
 
There's really nothing to gain by building from ports if you're going to stick to the default options.

Maybe this is a "blue moon" scenario, yet an example of something to gain by building from ports with default options, is an 11.1-RELEASE host with functional VirtualBox bridged networking.

Since the VirtualBox package is built on 11.0-RELEASE, and a kernel change between 11.0-RELEASE and 11.1-RELEASE broke its bridged networking support (the 11.0-RELEASE built kernel module will load in to an 11.1-RELEASE kernel, yet it won't work), building from ports is the only way to achieve a working host. 'not sure how many other people use or care about VirtualBox with bridged networking; for me it's one of my main workstation applications.
 
Since the VirtualBox package is built on 11.0-RELEASE
No, it isn't. Packages are built against the latest, supported, versions (11.0 is EoL). So at this point in time packages for 11.x are specifically built for 11.1.

The support schedule changed a bit from 11.0 and later. Now only the latest minor version will be supported. This is different from the previous schedule when you had multiple supported minor versions with different lengths of support ('normal' or 'extended').
 
Absentmindedly running pkg upgrade and realizing that your MariaDB 10.1 client is suddenly replaced with the MySQL 5.6 client. Because the official packages use MySQL 5.6 by default and my own installations use MariaDB. Or worse, getting LibreSSL and OpenSSL mixed up. Or Python versions, or Ruby, LUA, PHP and a bunch more. And those are only the obvious ones.


No, but then you won't have a reason to build from ports to begin with. There's really nothing to gain by building from ports if you're going to stick to the default options.

Aha! Then I see. Yeah, that would be a bummer I can imagine.

Regarding the PS, I realised now that I meant if you could run into those problems even if defaulted options "are included"; I don't hang out in the ports building defaults only. :D The answer is still "No"? (And yes, you can reply "Yes" to this.)
 
No, it isn't. Packages are built against the latest, supported, versions (11.0 is EoL). So at this point in time packages for 11.x are specifically built for 11.1.

I believe that during the time period 11.0-RELEASE was still supported, and 11.1-RELEASE was available (the overlap time), what I posted was true.

Maybe it's no longer true now that 11.0-RELEASE is EoL ('great news for me actually). And maybe this kind of issue (a kernel change between minor versions that breaks compatibility) really is rare; 'not sure.

My point is that there are times when there's something to gain by building from ports with all defaults (and with a non-exotic seeming use case, nonetheless).
 
Regarding the PS, I realised now that I meant if you could run into those problems even if defaulted options "are included"; I don't hang out in the ports building defaults only. :D The answer is still "No"? (And yes, you can reply "Yes" to this.)

If your ports uses the exact same (default) options as the official packages, then no, you won't run into problems. You could have a slight version discrepancy though, the port you installed could be slightly newer than the available package. I'm not sure how often the packages are updated and build but I believe it's now multiple times per week. As everything starts with a port it's possible the port version is newer because the corresponding package hasn't been built yet.
 
I only make 5-6 changes from default values when I use ports, but use them exclusively. I can count on one hand the times I've mixed them and then only as a last resort.

Yes, pkg is much quicker. I had OpenBSD on my T43 in a hour with pkg, ports might have killed it. But there is a certain satisfaction to be gained from compiling all your own programs I don't get with pkg.

And I am now a speed reader from watching all those screen of text fly by. ;)
 
But there is a certain satisfaction to be gained from compiling all your own programs I don't get with pkg.
Yes, definitely, but...

Two weeks ago I have changed my main system from FreeBSD11.1-STABLE to RELEASE and switched from a poudriere repository to the official one. Why? The first time I have followed STABLE has been the introduction of vt(4) some time ago. Since that time I also have tried lost of tweaking on the kernel and configuration just for fun and basically without issues. The same applies for using the ports tree. Currently I do not need any ports with non default settings. Since compiling devel/llvm50 or lang/gcc6 is no fun anymore I decided to switch back to packages

But I still have jails active, for example for the browser. And if I have the need to do some uncommon stuff I can easily clone my basejail and do that things there. Making a custom kernel is no issue as well, it just works. And about ports-mgmt/poudriere? It just works well. There is no real difference in experience in using the FreeBSD packages.

I can easily switch back to some custom kernel or to ports if desired or if necessary. But I encourage everybody to build a custom kernel and to use the ports tree, just to get the experience. Without that feeling one could also by a computer with preinstalled software.

And what about the professionals? Sometimes they are forgotten. This are the guys who need FreeBSD as such a rock-solid platform. Amateurs like myself can abuse FreeBSD as playground without shooting in their feet :beer::).
 
Greetings all,

I would like to pose the question from a different angle. Let us say that a person starts with packages. Later, for perceived or real want or need, alters some of the options and compiles the application from ports. Now, there is a potential for a problem. So, what now?

Given the excellent tools available ports-mgmt/poudriere, ports-mgmt/synth, and the fact that the compilation may be carried out during down time, and/or that people have often more than one computer, would the safest way not be to install one of such tools and use ports?

Kindest regards,

M
 
And what about the professionals? Sometimes they are forgotten. This are the guys who need FreeBSD as such a rock-solid platform. Amateurs like myself can abuse FreeBSD as playground without shooting in their feet :beer::).

I'm just some guy sitting at home with a bunch of computers running BSD, but a rock-solid desktop is an absolute must for me, too, and I get one Every time using ports.

A rock-solid custom desktop from the ground up, no less. :)
 
There's really nothing to gain by building from ports if you're going to stick to the default options.
At one point I needed to have password support in OpenVPN. That required enabling that option in compiling, as the default (sanely) is to not have that. So after an update using packages, the port would have to be rebuilt. I imagine there are numerous examples like this.
 
Mixing ports and packages question
You just have to know what You are doing and know the consequences.

For example I use packages for 99% of packages and Ports fir that 1% that is either not available as package (exFAT/lame) or I need to use different options the the default ones (lame option for ffmpeg).

On the server side, for example the default php version in FreeBSD is 5.6 (php56) but You want to use the 7.1 version (php71), in that situation I do not use pkg and use only Ports with portmaster for upgrades.
 
At one point I needed to have password support in OpenVPN. That required enabling that option in compiling, as the default (sanely) is to not have that. So after an update using packages, the port would have to be rebuilt. I imagine there are numerous examples like this.
Currently I have two ports installed by make which are x11/sterm and x11-wm/dwm. I have locked this two ports using pkg lock. There is nothing else which depends on this ports, and I guess there will never any security issue. Then it is fine to open the lock and run make again just in case of any updates. May be this is not practical with a port which has more relations to others.
You just have to know what You are doing and know the consequences.
Yes, I agree. Fortunately my variations from default are currently on a quite simple level.
 
[Interesting thread!
As I am going to set up a new FreeBSD installation on my second PC soon, I have a number of questions, as I am thinking about whether it could be a good idea to use ports only this time.
Before I ask, I have to say that I already experienced problems with ports/pkg mixed, mainly library conflicts (maybe caused by pkg defaulting to quarterly?). And would love to avoid to happen this again.

So my stupid questions that I do not find answers for in Handbook Chapter 4:
  • Is there a ports equivalent to pkg autoremove, to avoid unused/unneeded stuff piling up when trying programs and deleting those I decide not to keep? solved
  • Is it possible to keep my individual port configuration options when doing portupgrade?
  • Is there an equivalent to pkg lock in ports, for example when I modified some program and want to run portupgrade? (Edit: Can I use pkg lock for this, as chrbr's post above suggests?) solved
  • Will it be easy to upgrade that when 11.2 finally gets released?
 
Hello Snurg,
the most simple path to avoid issues but keeping the flexibility of ports is ports-mgmt/poudriere. It just works as documented. Many users are very happy with ports-mgmt/synth, I have not tried it up to now.
Is there an equivalent to pkg lock in ports, for example when I modified some program and want to run portupgrade? (Edit: Can I use pkg lock for this, as chrbr's post above suggests?)
If you use svnlite() to update the ports tree there are possibilities to lock something. But then it is not easy to revert the things, this is at least my experience :rolleyes:. It may be better not to touch that. And even if you use ports and if I am not wrong pkg lock should be effective, too. From my understanding everything ends up as packages and is handled by pkg[/pkg].
 
chrbr Sounds reasonable! Still not sure what's better, poudriere or synth. I guess I'll try Synth first, as it sounds sweet to have parallel building, making use of multiple cores for quicker building. (If I don't like it, I still can throw away and clean reinstall to use poudriere).
Then the questions about autoremove and pkg lock are practically solved. I think I just can diff/backup the modifications I do and restore the modifications after upgrading the sources to avoid the problem with locking source ports.
 
Back
Top