Questions from the "About ports and (binary) packages" howto

monwarez said:
Jose said:
So 17 out of 44 thousand means that mixing ports is inevitable? I'd never even heard of most of those, and I've certainly never needed them. If I did, I'd either run a system with just ports or make my own packages.

Saying that mixing ports and packages is "inevitable" is so wrong, it's just plain stupid. It's also bad advice to giv
Click to expand...
Click to expand...

Nobody said is was inevitable for every user. The conditions under which it cannot be avoided have been clearly stated twice now.

So Joe Ubuntu user decides to try out FreeBSD. He quickly installs most of what he needs using binary packages and is pretty satisfied with the experience. Now he wants to watch a DVD and finds out that there is no binary package published for libdvdcss.

What are you going to tell him? Don't install it from ports because mixing ports and packages is "bad"? Run "pkg delete -a" and reinstall everything from source (which will take days) because that's the right way? Set up your own package server and populate it with poudriere?

Preaching dogma is no way to provide good advice. There are pitfalls when mixing ports and packages, most of which result from your ports tree and installed ports/packages being out of sync. Explaining exactly what those pitfalls are and how to avoid them is a far more intelligent approach.
 
outpaddling said:
What are you going to tell him? Don't install it from ports because mixing ports and packages is "bad"? Run "pkg delete -a" and reinstall everything from source (which will take days) because that's the right way? Set up your own package server and populate it with poudriere?
Click to expand...
Absolutely. Especially if he's Joe Ubuntu. He's likely to run into a problem he can't even begin to solve if he mixes ports and packages. He'll conclude that Freebsd is "broken" and stop using it at that point anyway.
Besides, how' Joe Ubuntu going to feel when he discovers what he has to do to watch Netflix?


ill-protect-you-ill-keep-you-warm-until-youre-ready-21405659.png
 
Jose said:
Absolutely. Especially if he's Joe Ubuntu. He's likely to run into a problem he can't even begin to solve if he mixes ports and packages. He'll conclude that Freebsd is "broken" and stop using it at that point anyway.
Besides, how' Joe Ubuntu going to feel when he discovers what he has to do to watch Netflix?


ill-protect-you-ill-keep-you-warm-until-youre-ready-21405659.png
Click to expand...
No, he won't have problems with this simple scenario as long as he keeps everything up-to-date:

pkg upgrade
cd /usr/ports && git pull
cd multimedia/libdvdcss && make clean deinstall reinstall

It's that simple and many people do this sort of thing regularly without ever having an issue.

or...

auto-mark-install-from-source multimedia/libdvdcss
auto-update-system

auto-update-system will automatically reinstall libdvdcss if the installed version is older than the one in ports. I have at least half a dozen ports marked this way on each of my installations. I've been using this for a long time and never had a single problem result from it.

Time to let go of meaningless generalizations like "mixing ports and packages is always bad". It obviously depends on the state of your installation. If everything is kept up-to-date, problems are extremely unlikely.
 
Jose said:
Absolutely. Especially if he's Joe Ubuntu. He's likely to run into a problem he can't even begin to solve if he mixes ports and packages. He'll conclude that Freebsd is "broken" and stop using it at that point anyway.
Click to expand...
Did everyone forget drm-kmod upgrade troubles already? Whatever your preference is, don't bring strawmen "new users" here — keeping a desktop system exclusively using official binary packages is pretty much impossible in practice considering how often they are broken.
 
shkhln said:
Did everyone forget drm-kmod upgrade troubles already? Whatever your preference is, don't bring strawmen "new users" here — keeping a desktop system exclusively using official binary packages is pretty much impossible in practice considering how often they are broken.
Click to expand...
So use ports, or get an Nvidia card. This is isn't complicated.
 
Jose said:
Absolutely. Especially if he's Joe Ubuntu. He's likely to run into a problem he can't even begin to solve if he mixes ports and packages. He'll conclude that Freebsd is "broken" and stop using it at that point anyway.
Click to expand...
So, you have a problem with the browser, and want to quickly try a different browser for test. The different browser brings along as prereq its special version of llvm and qt5-webengine. That is already seven hours on my i5 (and one can run FreeBSD as a desktop with slower machines). At that point you have by long forgotten what you actually wanted to test.
This is the problem. Going with ports is all fine in a planned environment and for regular upgrades. It is very different on a desktop where you want to do something, say, with pictures or music or such, and have to try out what software is available and what it can do.
I don't say You're wrong! I say this is a problem and there is apparently no solution. Well, there is a solution: fetch the packages and don't forget to clean up afterwards. But people are rarely fond of clean up - if a configuration is found that works, it gets neither documented nor reproduced - it just stays to be used, until the next upgrade when it will likely break.
 
I finally figured out the reason why one cannot mix ports and packages: ports are installed with pkg add, packages with pkg install.

Then, when mixing ports and packages, we need to install some with pkg add, and others with pkg install. This does not work: pkg add will complain about missing dependencies, instead of fetching them from the network.
We could then do this:
Code: 
pkg add -M <packagename>.t??
pkg check -yd

pkg add -M should ignore the missing dependencies, and pkg check -yd would then supplement them from the repository. But it does not work:
Code: 
+ chroot /mnt sh -c 'pkg add -M /tmp/vb/git-2.31.1_1.t??'
Installing git-2.31.1_1...
pkg: Missing dependency 'curl'
pkg: Missing dependency 'expat'
`-- Installing gettext-runtime-0.21...
pkg: Missing dependency 'indexinfo'

Failed to install the following 1 package(s): /tmp/vb/git-2.31.1_1.txz
pkg will indeed ignore the missing dependencies for git-2.31.1_1, but then, when installing the dependencies that are available, it comes across their missing dependencies, and then it fails. The -M is not inherited to subsequent invocations.

[usecase]
 
Last edited:
PMc said:
I finally figured out the reason why one cannot mix ports and packages:
Click to expand...
I am not sure about that. I am not saying the pkg add/install is wrong, what I mean is I understood that packages are built less frequently (quarterly?) and ports are constantly up to date. So, dependencies for ports could be newer than dependencies for a given build of packages. For example: a shared dependency between package "A" and port "B" would be upgraded when you built port "B" but then that breaks package "A" because the dependency is now newer than what package "A" was built against. I think I am saying that correctly.
 
If you use quarterly packages + quarterly ports, both will have the same versions so you won't get into that kind of trouble.

If you use latest packages + latest ports, you may encounter such a problem from time to time, but it should be solved in a few days.

Mixing quarterly + latest is likely to be problematic.
 
bsduck said:
If you use quarterly packages + quarterly ports, both will have the same versions so you won't get into that kind of trouble.

If you use latest packages + latest ports, you may encounter such a problem from time to time, but it should be solved in a few days.

Mixing quarterly + latest is likely to be problematic.
Click to expand...
The quarterly ports branch is not as stable as advertised. That plus the fact that it takes several days for the official Poudriere runs to finish means you can still run into trouble even if you stick to the quarterly ports branch and quarterly packages.
 
shkhln said:
Did everyone forget drm-kmod upgrade troubles already? Whatever your preference is, don't bring strawmen "new users" here — keeping a desktop system exclusively using official binary packages is pretty much impossible in practice considering how often they are broken.
Click to expand...
The drm-kmod issue was actually what prompted me to develop auto-mark-install-from-source and the accompanying functionality in auto-update-system. This allowed full updates without breaking Xorg via the following:

auto-mark-install-from-source graphics/drm-fbsd12.0-kmod kbi

With this in-place, auto-update-system rebuilds and reinstalls drm-fbsd12.0-kmod from source after upgrading installed packages and updating the ports tree.

Background for those who don't know what it's about: The FreeBSD project aims to maintain full binary compatibility throughout each major release, so binaries built on 13.0-RELEASE should work on all future 13.X installations, for example. In 12.2-RELEASE, however, there was a change that caused the drm-kmod binaries from 12.1 to fail. One set of packages is published for each major release and they are built on the oldest supported release. So for the 3-month overlap of support for 12.1 and 12.2, those of us running 12.2 had to build the drm-kmod modules from source rather than use the binaries from 12.1. When 12.1 reached EOL and package builds started running on 12.2, this issue went away.

Joe U. is not a straw man, BTW. A straw man is a non-existent and unrealistic opponent invented to create the appearance of winning a debate. The scenario faced by Joe U. is very real and quite common.
 
drm-kmod:
outpaddling has the it as best as I recall from following the mailing lists and other places to complain. It was the first breakage that I recall in a long time.

Time to build everything and push to all content servers in relation to "new quarterly packages available" is a legitimate concern, one that is being mitigated as best they can. It's difficult to keep users from peeking early.
 
Jose said:
The quarterly ports branch is not as stable as advertised. That plus the fact that it takes several days for the official Poudriere runs to finish means you can still run into trouble even if you stick to the quarterly ports branch and quarterly packages.
Click to expand...
Adding a new port to quarterly (the subject of the "not as stable" link) is not a problem. The thing that is essentially forbidden in a MFH is a change to an existing port that breaks compatibility with other ports in the branch.

Your concern about the few days it takes to generate packages following a commit is valid in theory, but I've never had an issue with it in practice, even working with latest/head. Most port upgrades don't alter the API in a way that will break anything, so the chances of getting tripped by this is very small. It is worth watching out for if you mix, though.

Note also that the "few days" rule only applies to x86, for which we have a large build cluster. powerpc and arm -latest packages are not kept up-to-date (at the time of this writing), so if you need to mix ports and packages on those platforms, quarterly is much safer at this time. Hopefully this will change in the near future.
 
outpaddling said:
Quarterly is actually very stable. Adding a new port to quarterly (the subject of the "not as stable" link) is not a problem. The thing that is essentially forbidden in a MFH is a *change* to an existing port that alters the API/A
Click to expand...
Your reading comprehension is not strong. Here's what the "stable" ports branch is supposed to be
Quarterly branches aim to receive (on a best effort basis) only the following Merge From Head (MFH) commits, including, but not limited to:

  • Security fixes (that may be version updates, or backports of commits)
  • Build, run, packaging, or other bug fixes
  • Ports compliance/framework changes
More precisely, the changes a quarterly branch receives is:

  • Any change that is not a version update (unless it is a security update), that other than the intended change, makes no functional change to the resulting package or software.
Click to expand...
Not new ports.

No nonsense about "altering the API/A" whatever that is.
 
Your reading comprehension ain't so hot, either.
including, but not limited to:
Click to expand...
How about you tell us, in your own words, what that means.

By the way, it doesn't help your position that your source for "The quarterly ports branch is not as stable as advertised" is literally a link to your own complaint. That's not a "source". That's just you jumping up and down and demanding people pay attention to your issue.
 
PMc said:
So, you have a problem with the browser, and want to quickly try a different browser for test. The different browser brings along as prereq its special version of llvm and qt5-webengine. That is already seven hours on my i5 (and one can run FreeBSD as a desktop with slower machines). At that point you have by long forgotten what you actually wanted to test.
This is the problem. Going with ports is all fine in a planned environment and for regular upgrades. It is very different on a desktop where you want to do something, say, with pictures or music or such, and have to try out what software is available and what it can do.
I don't say You're wrong! I say this is a problem and there is apparently no solution. Well, there is a solution: fetch the packages and don't forget to clean up afterwards. But people are rarely fond of clean up - if a configuration is found that works, it gets neither documented nor reproduced - it just stays to be used, until the next upgrade when it will likely break.
Click to expand...
If I know a compilation takes 7 hours (like compiling the kernel before I discovered the -j4 make switch), I just do it overnight.

As for forgetting what I wanted to test - this is why I keep sort of a 'Diary' with what I wanted to test, why, what I did, what I installed, in what order, where I picked up a useful command, what I installed, what version - and what errors I got. That proved incredibly helpful with troubleshooting and asking for help later. And yeah, if I found a config that works, sometimes I bother documenting it, sometimes I don't. I started keeping the diary in 2003, back when I was messing with Linux. Continued with FreeBSD, the journaling habit served me well.
 
Over the past month I had a series of 3-4 failed builds I didn't pursue when using ports-mgmt/portmaster to build new programs on this machine already successfully built on others. I did a couple days ago when www/youtube_dl had problems, and they led deep down a rabbit hole in different directions.

I carefully read /usr/ports/UPDATING, (that didn't help) worked at it and tried a lot of things, including seen mentioned recently in threads. Mixing pkg and ports was the only way I saw to fix it, and I could tell things were about to get worse if I didn't get it fixed.

I ran the build as usual and when it stopped I used pkg to install the base program that was stopping the rest from building and then restarted the build with portmaster. I used pkg to install four different programs and compiled the rest, but that's what it took.

I used shutdown -r now when I was done and everything is copacetic
 
Trihexagonal said:
Over the past month I had a series of 3-4 failed builds I didn't pursue when using ports-mgmt/portmaster to build new programs on this machine already successfully built on others. I did a couple days ago when www/youtube_dl had problems, and they led deep down a rabbit hole in different directions.

I carefully read /usr/ports/UPDATING, (that didn't help) worked at it and tried a lot of things, including seen mentioned recently in threads. Mixing pkg and ports was the only way I saw to fix it, and I could tell things were about to get worse if I didn't get it fixed.

I ran the build as usual and when it stopped I used pkg to install the base program that was stopping the rest from building and then restarted the build with portmaster. I used pkg to install four different programs and compiled the rest, but that's what it took.

I used shutdown -r now when I was done and everything is copacetic
Click to expand...
Based on this weekend's study of portmaster(8), I do recall seeing info that ports-mgmt/portmaster can be asked to use pkg for build-depends deps, and even remove them afterwards if they're not needed...

What I did this weekend is do a dry run with # portmaster -n x11/kde5, and it did produce a list of ports that would be installed. I ran that on an empty ports tree. My question here is, would running # make config-recursive x11/kde5 before the dry portmaster run make any difference?
If it does, I'm gonna be a step closer to solving the mystery of upgrading KDE in-place, without dependency hell.
 
I had to install security/p11-kit and dns/libidn2 using pkg. multimedia/ffmpeg was problematic as well and overall, had what I, myself, would classify as a mess to clean up.

Now I'm updating another that showed an error in the icon path due to a missing .so in graphics/gegl, that has already stopped with the same "FAILED: meson-build" error when compiling as this one did.

Which is of some import, but can't see where at the moment, and played a part in resorting to use pkg to fix this machine.

It's now successfully compiling starting from the second port listed in the portmaster error in hopes I can move past the fail point and finish in compiling gegl.
 
Usually, if meson fails, that's because of race conditions I created myself with the -j4 make flag... In those cases, I remove the work/ port directory, and re-run make without the -j4 flag.
 
This was the FAIL message I got:
Code: 
FAILED: install script '/usr/local/bin/meson --internal yelphelper install --subdir=help/manual --id=gtk-doc-manual --installdir=share/help --sources=index.docbook@@fdl-appendix.xml --symlinks=true' exit code 1, stopped
FAILED: meson-install 
/usr/local/bin/meson install --no-rebuild
ninja: build stopped: subcommand failed.
*** Error code 1

Stop.
make: stopped in /usr/ports/textproc/gtk-doc

===>>> make stage failed for textproc/gtk-doc
===>>> Aborting update
I reinstalled meson but that did not work. It came down to installing textproc/gtk-doc by pkg.

I also was missing dependencies:
Code: 
Updating database digests format: 100%
pkg: gegl has a missing dependency: ilmbase
pkg: itstool has a missing dependency: py37-libxml2
pkg: gimp-app has a missing dependency: ilmbase
pkg: libinput has a missing dependency: py37-pyudev

So I complied gimp, itstool and libinput with portmaster, then ran portmaster -a but that gave a failure with this error:
Code: 
===>>> Returning to update check of installed ports

===>>> The misc/qtchooser port has been deleted: No longer supported upstream
===>>> Aborting update

root@bakemono:/ # portmaster misc/qtchooser
make: chdir /usr/ports/misc/qtchooser: No such file or directory

===>>> The misc/qtchooser port has been deleted: No longer supported upstream
===>>> Aborting update

I updated what it found to that point and everything seems to be running fine now.
 
You must log in or register to reply here.
Back
Top