Ports Tree Philosophy Upgrade Needed

Please, explain me why must I update or remove LibreOffice
For the removing part, it might be related to this bug report. If it is the case, it should be taken care of quickly I suppose.

Some time ago 0install was even present in ports tree, I don't know why it was delete
Yes that's true : devel/zeroinstall-injector. And the reason it was remove is no more valid if we consider PBI abandoned. If you feel the need of it, you could make a port of the software. At the moment, it seems that there is a problem with FreeBSD. But as you can see, a fix is available.

For a more general perspective, I never had any issue while updating my ports(7) but I update everything not some software only. As far as I know, the ports has to be taken as a whole and I have hard time to find a simple solution to your problem where you want to upgrade some software and not some others (I am not the more qualified though).

Hopping you will find what you seek with 0install.
 
Do I want to remove libreoffice-4.3.7?? NO!!!
Do I want to update xorg-server?? NO!!!
I just want to install freerdp because I need it NOW!
But the current pkg system does not allow me to install the freerdp package without updating some important parts of my system. This is a hell, I don't want to do all the updates now, I have no time, I've just asked to install freerdp!

This is because the main package repository is built from the HEAD ports tree. It's a rolling-release distribution system--update one thing, and you need to update everything else along with it. There is not and cannot be any alternative. Updating a rolling-release system piece-by-piece is absolutely guaranteed to break something eventually--not one rolling-release Unix-like system I know of supports this, with the exception of NixOS, which is built from the ground up specifically for this one feature. The only alternatives FreeBSD offers you are to build from ports (since you have to manually update the ports tree) or use the quarterly package repository. That's it.[1] I don't want to speak for the developers, but it seems to me the chances of this changing any time in the foreseeable future is slight, since pkg(8) is inherently dependent on the structure of the ports system. If this is too inconvenient for you, that's fair enough, but FreeBSD may not be for you.

Please, explain me why must I update or remove LibreOffice (BTW, the last version does not work correctly on 10.1) when I just need to install freerdp??

Shared dependencies. Package a depends on version 1 of package x, while package b requires version 2 of package x.

Why does my Mac OSX not ask me the things like this?

If you used MacPorts or Homebrew, it would.

Why does my Windows not ask me neither?

Why doesn't my electric car take diesel?

[1]: This isn't strictly true: as a third alternative, you could also use pkg lock <package_name> to prevent a package and its dependencies from being upgraded, but this raises the maintenance burden rather than making things more convenient.
 
Peter2121, I think we need another FreeBSD fork again. ;-)

I think you should fork it, or quit the complaining and help out with PC-BSD development. That way the Project can continue to thrive without any more desktop related doom and gloom non-sense, complaints, and FUD.

It's amazing how some people (mostly Linux refugees) think FreeBSDs future sustainability is dependent on whether or not it's a viable desktop.
 
We are still stuck with the ancient ports system that should have been rewritten ages ago. It has few major flaws. Fixed dependencies that prevent ports depending on abstract entities such as "any perl version 5.16 or higher". The other one is that it's not possible to mix parts of the ports tree with the older contents of ports tree, essentially downgrading to earlier versions easily. There is no proper API in /usr/ports/Mk/* that would enforce compatiblity forwards or backwards, the only guaranteed way that anything works is that the all of the tree is from same point in time. The one other thing that the portmgr@ people have expressed dissatisfaction is the format used to express the ports themselves, Makefiles are very bad for expressing declarations because of the arcane parsing rules and other wierdness, there's also the problem that Makefiles allow port maintainers to write make(1) or sh(1) code in their Makefiles that nobody else understands when they try to fix the port. Something like UCL (that is used in pkg as the configuration file format) would be much better for the task.
 
Updating a rolling-release system piece-by-piece is absolutely guaranteed to break something eventually--not one rolling-release Unix-like system I know of supports this, with the exception of NixOS, which is built from the ground up specifically for this one feature.
Why does the approach of NixOS cannot be used in FreeBSD software management? ;)
 
drhowarddrfine,
My system is almost up-to-date, I've updated all packages three or four month ago approximately.
My system gets updated daily. You forget that packages and ports, such as LibreOffice, are written by third-parties and not FreeBSD. Any complaints about updates should be brought up with those third parties, not FreeBSD which only passes them on to you.
Why does my Mac OSX not ask me the things like this? Why does my Windows not ask me neither?
They aren't as up to date. Internet Explorer only updates when they feel like it, years apart, while Firefox and Chrome updated on a six-week schedule. IE is the worst browser on the planet while Firefox and Chrome are light years ahead. And no one is complaining about that.
 
Why does the approach of NixOS cannot be used in FreeBSD software management? ;)
...NixOS ... is built from the ground up specifically for this one feature.

To really emphasize this: the NixOS Linux distribution was created for one purpose only--as an experiment for the founder's PhD thesis. The entire OS is built around a package management system that absolutely nobody else uses, and maintaining the distribution means having a group of people dedicated to building and maintaining several versions of every single package available, while requiring users to frequently tweak and pick at various configurations and individual parts of the system (including the "base system") to maintain system integrity. NixOS has been around for roughly a decade, and virtually nobody has heard of it. It isn't used in any critical/professional setting--while I don't doubt that it's possible to use NixOS as a personal production system, and that some of its dedicated users do so, it quite simply has always been a novelty.

I've got no problem with the ports and package management systems undergoing some refinement, and I'd bet no-one else really does either. But it would have to be something that is both manageable and arguably and demonstrably better than what already exists. I think there's one thing that really, really needs to be stated here: there are indeed other Unix-like systems (namely, Linux distributions such as Gentoo, Arch, NixOS, and CRUX) that allow users to install and individually update multiple versions of a single port/package. But these package management systems require a greater degree of hands-on system maintenance. They do not make anything more convenient, and they absolutely do not make anything more "stable". They increase system complexity, making things less convenient and (at least arguably) less stable. There's a weird trade-off involved, whereby you don't merely always have access to the latest packages, but must in fact frequently update to avoid problems. Update too frequently, and you risk running into previously undiscovered bugs (since you're among the first users to install the new package); don't update frequently enough, and one large update later on is more likely to break your installation. As a former Arch Linux user, I can say that:
  • if every time you install a new package in Arch, you're expected to completely update every other package simultaneously;
  • if you break your Arch system by updating individual packages you won't get any sympathy or help from the community; and
  • the common wisdom in the Arch community is that if you go more than six weeks or so without completely updating every package on your system, it's recommended to just perform a clean install.
The fact that FreeBSD has managed to deftly avoid this kind of conundrum and find something in the middle--access to the latest software, but only when you want it--is the primary reason I switched to it from Arch. Unfortunately, this means either tracking one package repository and waiting for version bumps, or building everything from source. Personally, I can live with either.
 
Why does the approach of NixOS cannot be used in FreeBSD software management? ;)
Patches accepted.
LOL!!!

I like the Nix approach. At this time, my FreeBSD system is ALMOST perfect. It's just that when some upgrade is needed, anxiety goes to the roof. With my FreeBSD experience so far, it's well within reason. I'd love to help contributing more to FreeBSD, but the learning curve is overwelming. I only have a few small success stories so far, all documented in this forum.

I must admit that I'm very tempted by the NixOS solution. I'll try it first in a VM if it works for me. And install the QVWM WM that I'm curently using on FreeBSD.

Dominique.
 

I'm not kidding much. That's how everything got started. You want something in ports, you do the legwork yourself and prepare port and PR. You want an update to a port, same thing. The basic workflow hasn't changed a bit.
 
Ditto.

I don't get it. Sure, I occasionally have a hiccup when I upgrade a port but, otherwise, I've been running a FreeBSD desktop for 11 years! What's the big deal? It's not hard. Everything works. And I work on my workstation possibly longer in a day than anyone else.

I just don't get it.

Sorry, if I was not clear enough. I meant that FreeBSD is good as desktop and people should try it before speak so quickly. We have a good OS that cover our necessities and that's the most important for me besides the great FreeBSD Community.

Hope that you can see now my viewpoint ;)
 
Any complaints about updates should be brought up with those third parties, not FreeBSD which only passes them on to you.
No problems with software updates, the problem (once again) is that I must install ALL updates or NOTHING.

IE is the worst browser on the planet while Firefox and Chrome are light years ahead. And no one is complaining about that.
Few people are using IE now, even on Windows. But Windows let me choose - what version of Chrome or Firefox could I install. It does not force me to update Chrome when I want to update Firefox.

maintaining the distribution means having a group of people dedicated to building and maintaining several versions of every single package available
So the small team of unknown distrib can accomplish this task, too complex and impossible for FreeBSD community? ;)

there are indeed other Unix-like systems (namely, Linux distributions such as Gentoo, Arch, NixOS, and CRUX) that allow users to install and individually update multiple versions of a single port/package. But these package management systems require a greater degree of hands-on system maintenance. They do not make anything more convenient, and they absolutely do not make anything more "stable".
I don't think that the approach of Arch or Gentoo is great. That's why I'm using FreeBSD desktop ;)
Probably, the best path is in the middle - define a "base FreeBSD desktop system", larger than simply a FreeBSD base system. Inside this base system one need to update all or nothing (like today). And additionally we need a way to install applications with all their dependencies like in NixOS, but it should mainly concern large desktop applications with tons of dependencies (like LibreOffice).
 
Peter2121 Then you must not understand how these things work. As pointed out earlier, some updates are necessary for software to run. If you don't update the dependencies, then the interfaces won't work or the security is bad or any number of other reasons.

Few people are using IE now, even on Windows.
I'm a web developer and that's not true at all but I don't want to go off on that tangent.

FreeBSD does NOT force you to update Chrome, or ANY program, any more than Windows does. Nor does Windows let you choose. In your case, it's the software you are trying to install that's telling you that you must update or the software won't run cause due to incompatibilities! Windows and Linux are the same way. You have to keep your dependencies, drivers, etc. up to date or they won't run!

Probably, the best path is in the middle - define a "base FreeBSD desktop system"
Then you are stepping outside the bounds of what FreeBSD's goals and purpose. If you want that, that's what PC-BSD is for.

Inside this base system one need to update all or nothing
But that's what you're here complaining about.

And additionally we need a way to install applications with all their dependencies like in NixOS
FreeBSD DOES install all the dependencies. How NixOS does it, I don't know, but then someone would come along and complain we need to do it "just like XXX ... cause theirs is better".
 
FreeBSD doesn't [necessarily] need to be forked. What can be forked is the ports system to something that is more efficient. Something like NetBSD's ports. I tried that OS, but couldn't continue with it, because of its lack of wireless network compatibility.

I will learn over the next few years, and contribute more than documentation.
 
...
I will learn over the next few years, and contribute more than documentation.

I highlighted the words I like to see. More folks throwing in quality assistance is what we need and not forks that will stagnate. Start learning. Dig into a problem that concerns you and contribute back a quality fix one issue at a time.
 
Code:
[root@pcbsd-peter] ~# pkg install freerdp
Updating pcbsd-major repository catalogue...
pcbsd-major repository is up-to-date.
All repositories are up-to-date.
The following 50 package(s) will be affected (of 0 checked):
Installed packages to be REMOVED:
  libreoffice-4.3.7
Do I want to remove libreoffice-4.3.7?? NO!!!
I think we can agree this isn't ideal, but removing a package without a replacement shouldn't happen often. What I guess occurred is that when editors/libreoffice and common dependencies between editors/libreoffice and net/freerdp were built in PC-BSD's ports-mgmt/poudriere run, a common dependency of editors/libreoffice and print/mupdf failed and you happened to update before the problem was fixed and the new, missing packages became available. As others have explained, for the most part, package dependencies are version specific. It's difficult to allow more flexibility.

Maybe this situation could be prevented if an updated repository didn't go live whenever any dependent ports fail in the net-mgmt/poudriere run.
 
I'll point out that something in ports is redundant in a useless way and unnecessary. (For some situations redundancy is good.) Afterwards, coincidentally or not it seems to be fixed. Then soon, things go back to being bulky, or broken, but at least features were added because that ability was added for what the developer probably dreamed of the program being.

Only by using FreeBSD did I realize that Linuxism based dependencies are a mess. Tons of not needed features have to get compiled to get something a feature to work, such as 1 file from a library, or a port that re-installs other software, whereas the package already has what's needed to do it is already in the install process. It's like a car having a second gasoline engine and transmission mounted on top of the hood just to run the windshield wipers, and another one to adjust the electric mirrors. It makes me wonder if people don't understand what the existing code does, but keep adding on to it. I don't either, but from a non-programmer's view I believe that there's enough evidence of a lot of redundant but unused code installed. Running into compile choices that lead to circular dependencies is another kind of evidence of inefficiency and redundancy. Packages would reduce install time, but still the packages become vulnerable to broken installs, stalling and crashing, because of their unnecessary complexity. Don't get me wrong, Linux capabilities and FreeBSD together are great.

I don't want to promote many forks, I only think 1 fork would do. A NetBSD package compatibility layer would also do, but that is probably outside of FreeBSD's interests. People have different ideas of what ports should be. I think there should be efficient code, and Linuxisms can be used on top of it to add functionality, but not for the sake of none other than being a Linuxism which brings in vast amounts of unused code. I only suggested a ports fork, because people don't want to abandon it, which is their right. That will require fixing the GNU/Linux community too, which is outside of BSD interests. Maybe my theory about dependency complexity is not completely accurate.
 
Last edited:
Only by using FreeBSD did I realize that Linuxism based dependencies are a mess.

You're incorrect here. The dependency model used by FreeBSD packages was not invented on nor copied from Linux but is very much homegrown out the technical features/limitations of the ELF file format, ld.so(1) style dynamic linking of shared libraries and the fact that no one could envision that someone would want to use binary packages from multiple sources. The dependencies are now handled essentially the same way as they were in the very first versions of the old pkg_* tools, they are just translated to SQLITE database entries.
 
They are a mess. It's not just the libraries, it's the ports that packages are built off of. Compare how smooth the base system of any BSD with little else runs to most Linux distributions. I've tried compiling on Linux systems in the past, and the option choices go on forever. I had to study the choices and write it down taking hours at a time to do just that. It fits their reasons to have many options: different priorities for different distributions. FreeBSD shows that this can be avoided, then run better.

People port programs the only way they know how, but without replacing Linux dependencies with what exists in the base install or minimal installations of BSD.

style dynamic linking of shared libraries and the fact that no one could envision that someone would want to use binary packages from multiple sources.

Isn't that a FreeBSD ports/package problem that is very similar to Linux problems?
 
They are a mess. It's not just the libraries, it's the ports that packages are built off of. Compare how smooth the base system of any BSD with little else runs to most Linux distributions. I've tried compiling on Linux systems in the past, and the option choices go on forever. I had to study the choices and write it down taking hours at a time to do just that. It fits their reasons to have many options: different priorities for different distributions. FreeBSD shows that this can be avoided, then run better.

People port programs the only way they know how, but without replacing Linux dependencies with what exists in the base install or minimal installations of BSD.



Isn't that a FreeBSD ports/package problem that is very similar to Linux problems?

It's the same problem and both sides have come up with various attempts to solve it independently but none of them are really satisfactory. So far the only way to guarantee smooth updates is to force a single source for the binary packages that are built from a source that known to be good. The latter condition "known to be good" is where FreeBSD ports stumbles quite often because it's rolling release with commits coming in at unpredictable times from various committers.
 
That happens too. One example of it being a rolling release that breaks certain features, is when installing an application that runs solely on one toolkit like qt4. That's expected, and normal.

One example of complicated redundancies is: Installing a program with gtk3, then some added features in the options goes back and pulls in gtk2. For that one program compile, I just want either gtk2 or gtk3, while I can have both on my system. I will admit that, gtk2 has been cleaned up somewhat.

Other times, it will be a qt4 dependent program. Usually it will work fine, but a newer feature will be available that a qt4 solution doesn't exist for that feature. It will pull in gtk, AND it will install tons of codecs, hardware access programs, when all but few of these functionalities are already included in the qt4 install queue.

It will need 1 audio codec, and it will install an additional set of every type of codec it can find. I'll want a solution from 1 tool, not 2 or more.

In short, 1 toolkit solution can pull in toolkit solutions that don't function with that program, except 1 (or few) minor dependency. 3 other duplicate bundles aren't needed, when they aren't meant to work with that toolkit dependency solution.

Another odd problem, is when gtk dependencies get pulled in for a non-graphical program install. It doesn't happen as often, but it does happen.

The packages built this way slow down the computer a lot, and cause a lot of potential for breakage.

This one, I don't expect anyone to fix, because I figure this is how they like doing it. When installing gtk3, it will pull in Jadetex, or texmf, for documentation/manpage translation from Gnu/Linux. It's ridiculous, that the whole compile has to stop to download 1 gb, at a very slow speed at times 4kb/s, not representative of my internet connection. Installing the package doesn't always bypass that inconvenience. I typically disable this on my own when I can. It's not manpages that I need to get that program working, but just for bloat. There was a bsd alternate ports/package solution for it, but it's port description says to use something better.

* edit
It may be necessary to install another solution from another toolkit, but it should be limited to that feature/codec. Not repeat an alternate bundle of codecs for what's not used/needed for that program.
 
This is me just dreaming, so don't take this one personally. I'd like to see a low-level purely BSD solution for libraries, dependencies, graphics and applications.

For instance purely BSD solution of Wayland, Xaw3d, Fluxbox, i3 metaports that are ready to go, and eventually to be installed by one command from the base-system of FreeBSD through ports/packages. BSD codecs too. Then other open-source solutions, including xorg, can build on top of that.
 
I will learn over the next few years, and contribute more than documentation.

More is better, but this makes it sound like documentation is a lesser part. A lot of people think that, but the applications and operating systems that succeed often do it on the strength of their documentation.
 
Documentation is important. I'm limited by what I don't know to document or otherwise contribute.

operating systems that succeed often do it on the strength of their documentation.
That's NetBSD's philosophy. Their documentation is neat, and their ports system is efficient.
 
Back
Top