Solved Thinking of going ports...

Someone here wrote: You install a Webbrowser with pkg, which needs something from another port, but this port you install using poudriere/portsmaster/whatever, and you switch off this option, and your Webbrowser dies.

Funny enough: For me it was actually the other way round.
I needed an option i could only get by compiling myself (the GlusterFS-Support in Samba).
Since i saw all those advices about NOT mixing pkg and ports, i'm now on poudriere with everything going via ports (except base-system)
Since it's a headless server (no XORG/Desktop), and it's an old rust-bucket of computer, the compile-times are "reasonable"
I admit: I use this "read which ports to compile from a textfile"-option. I have some 3-4 textfiles with different ports, so i can choose which ones to (re)compile.
e.g. in my first file there is stuff like sudo, nano, llvm ..... mainly ports that don't have many dependencies or are "biggies" (like LLVM) or are definitely coming up as dependencies later on (LLVM being such a prime candidate. Does FireFox still require Rust?)
the second file is network-related stuff (gluster, samba, ProFTPd etc.)
the third file has the (F)AMP-Stack (Apache, MySQL, PHP)
the fourth file applications like Nextcloud etc.
 
The biggest performance improvements will be from compiling a custom kernel, and removing unneeded dependencies from a port.

It's inefficient when Rust or LLVM has to be upgraded for a simple upgrade, or when upgrading 1 port causes the removal of many ports, then installation of ports. Another inefficiency is when an audio port calls in graphical ports, back to audio ports, or when any other port causes multiple crisscrossing from different categories.

I wish we could have the default documentation be of Sphinx, instead of Doxygen, for all packages/builds, no matter that it came from another OS or upstream. I wish Linux ports would be built directly on top of BSD ports, to reduce needless dependencies.
 
Don't go mixing ports and packages... portmaster works on /usr/ports. Mixing ports and packages invites dependency hell.
 
astyle said:
Even with minimal defaults being equivalent to pre-compiled packages, you still gain a snappier system - just because it was your processor doing the compiling, and not some unknown processor elsewhere.
Click to expand...

let's say in the 90...these things like compile for you procesor and flags..yes...it wort it
but today na..is too much time and effort for making,,I dont know 1% faster?

the only reason for compile a port is to add a option,disable a option o "hack" the source code
for example..change the order of buttons in the toolbar of pcmanfm
 
wolffnx said:
the only reason for compile a port is to add a option,disable a option o "hack" the source code
for example..change the order of buttons in the toolbar of pcmanfm
Click to expand...
How about recompiling VLC with libass and x265 enabled so that you can actually turn on subtitles on the newer movie formats? or re-compiling Akonadi against SQLite (package version of Akonadi is compiled against MySQL 5.7, which not only has vulnerability CVE's affecting versions prior to 5.7.34 , but in some cases requires manual config of MySQL for anything to work).

I don't even do any source code hacking, just recompiling against libs from a different project.
 
astyle said:
Don't go mixing ports and packages... portmaster works on /usr/ports. Mixing ports and packages invites dependency hell.
Click to expand...
That's good advise for people who don't have the experience to work through possible problems, if they should arise.

I've done it to get past the issue with python referred to in /usr/ports/UPDATING on seven laptops running FreeBSD 12.2-RELEASE-p7 and haven't had a problem on any of them.
 
astyle said:
Don't go mixing ports and packages... portmaster works on /usr/ports. Mixing ports and packages invites dependency hell.
Click to expand...
I don't use portmaster. I just build and update manually the few ports where I want custom options, and let pkg handle the rest. Never had a problem doing so.

To (re)install a port with custom options on a system using pkg:
# cd /usr/ports/example/port
# make config
# make install-missing-packages (so that all dependencies are installed as packages and only the requested software gets built from source)
# make
# pkg delete -f exampleport (if already installed from pkg, to remove the package without removing the ones depending on it)
# make install
# pkg lock exampleport (so that pkg doesn't replace the custom build with the default package)
# make clean

To update it afterwards:
update ports tree + packages
# cd /usr/ports/example/port
# make install-missing-packages
# make
# pkg unlock exampleport
# pkg delete -f exampleport
# make install
# pkg lock exampleport
# make clean

It may not be the most convenient method, but at least it's reliable, and it's still much faster than building your whole system from source when you only want custom options for, say, half a dozen ports. You may also do some scripting to streamline the process.
 
You must log in or register to reply here.
Back
Top