# I love FreeBSD: I wish ports were up to date



## eydaimon (Mar 15, 2019)

I love FreeBSD. I've been using it for over a decade now. I've used a number of different linux distributions as well as macos and it's package managers (homebrew, and macports)

My beef (and I love you all) is that I often come across ports that are out of date for quite some time.

The latest port I came across which was out of date is autojump: https://www.freshports.org/sysutils/autojump/

It's on version 13  which was released circa 9 years ago. Current version is 22  which was released 2017.  Normally the discrepancy isn't this large, but I will often see tools that are out of dates for weeks or even months.

Is this because ports are difficult to update, or some other process issue? Could it be simpler for anyone to contribute and update a port ?
homebrew seems to get updated a lot faster. It's probably due to adoption too, but I'm curious what thoughts are on this?


----------



## phoenix (Mar 15, 2019)

Anyone can contribute to the ports tree.

As there's a maintainer listed for this port, the first step would be to contact them to see if there's a reason for it not being updated, and possibly offer to help with updating it.  If you don't hear back from them, you can always prepare an update to the ports and submit it as a bug report in Bugzilla.  If there's still no response from the maintainer, you can even put in a bug report requesting to take over maintainership of the port.  

FreeBSD is only as good as the people volunteering to help out with things.


----------



## tedbell (Mar 15, 2019)

Agreed. I'm quite satisfied with the software selection in ports and they do update them daily. Besides, newer doesn't necessarily mean better.  I'd rather FreeBSD stay the rock solid, faithfully coded beast that it is.


----------



## malavon (Mar 15, 2019)

eydaimon said:


> My beef (and I love you all) is that I often come across ports that are out of date for quite some time.


I've seen a few of these too, ports that I used. Since FreeBSD is mostly run by volunteers, I decided to take a stab at creating some patches and getting them updated.
I can recommend doing this, not only do you help someone out (on top of yourself), but you'll learn something in the process.


----------



## eydaimon (Mar 16, 2019)

I used to be a portmaintainer for several years for multiple packages. However, I thought the process could be easier to do so.  

I tried emailing the maintainer for autojump but the email bounced so it looks like it should be taken over anyway.

homebrew is also run by volunteers and their packages are very fresh. That's why I'm wondering if there's something that could be made easier as far as process to update packages.


----------



## malavon (Mar 16, 2019)

Well, I recently updated the audio/amarok port to include QT5 support and apparently KDE ports can be updated with a simple Git PR.
I don't know if the other ports can be updated like this as well, but it would definitely make things easier.


----------



## Nyakov (Mar 17, 2019)

eydaimon said:


> However, I thought the process could be easier to do so.


I want to support this statement.

I currently in the middle of new, after 4 years, attempt to use FreeBSD on my desktop.
And it seems that software problems became more wild since then.

What is most frustrating is software in official pkg repository that just crashes at start. Or with attempt to use it.
Like doublecmd or shotcat for example.
blender.
And clinfo - this is show stopper for me.

I think, that having software in repository must mean something more then - it builds without major errors.
It must run as well.

I think this is conceptual problem. Software meant to be used, not to be builded, it is not the purpose of software. The same is relevant to the OS itself.

So the process of maintaining software, must be as simple and automated as possible.
More people must be involved. 
The involvement process must be as simple as possible.

*Broken version of software mus not be able to make its patch to repository.*


----------



## D-FENS (Mar 17, 2019)

Regarding clinfo, I suspect that it worked in general, when the port maintainer tested it. The problem is, there are thousands of different hardware configurations and unluckily yours (and mine too) is one of the ones that cause the program to crash.
It's a man power issue, there are simply not enough volunteers to maintain and test the ports on the platform with all kinds of hardware.
The package did not seem broken to the maintainer, so it made it into the repo.
I think we are getting a very decent system for free and I am very happy with it. It's not perfect, but whoever trips on the issues has the most inscentives to fix the bugs and share with the community. That's how open source project work.


----------



## Nyakov (Mar 17, 2019)

roccobaroccoSC said:


> The package did not seem broken to the maintainer, so it made it into the repo.
> I think we are getting a very decent system for free and I am very happy with it. It's not perfect, but whoever trips on the issues has the most inscentives to fix the bugs and share with the community. That's how open source project work.



Yes, we a getting something wonderful for free.

But the question is, *how to make it better.*

If problem was in the manpower, then how so some strange projects as mentioned here Homebrew gets so much working software?

So the problem can be technical - wrong approach for testing and porting.
And can be conceptual\social - the unability to get more manpower.

If manpower is the problem, then, does this problem on the main problems list for someone? FreeBSD foundation, Core Team?

I strongly suspect that it is not.
If it is so, then what we can do with this?


----------



## Vull (Mar 17, 2019)

The folks who provide us with FreeBSD for free only take care of the base system, which is top notch and gives them plenty to do. As I understand it, they don't maintain the ports themselves, but rather, they just provide "userland" with a place to put the userland ports, and provide delivery systems and resources like repositories and servers to support the ports, but unless I'm mistaken-- and please correct me if I am-- only userland is responsible for porting and maintaining the actual ports. I use a lot of the ports, but don't personally port or maintain any of them, and so I'm very grateful for all the port maintainers who do so on a voluntary basis. Thank you.

What can we do? Volunteer for port maintainership, I guess, or find some creative new ways to recruit more volunteers.


----------



## eydaimon (Mar 17, 2019)

Vull said:


> What can we do? Volunteer for port maintainership, I guess, or find some creative new ways to recruit more volunteers.



What I'm setting out to do is to see if there's a process problem. Volunteering and trying to find volunteers for a system that's possibly so cumbersome to use that itself is causing the problem wouldn't be the right solution.  Maybe the whole idea of having _one_ maintainer is flawed and a single point of failure and should be reconsidered. I don't know.  I remember thinking it was a burden to always be the one person to keep an active project up to date (I take my commitment seriously so I put in the work for it to stay current).

For some time I've considered porting homebrew to FreeBSD.  Updating a port here is something anyone can do: https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request

There are more details at https://docs.brew.sh/Formula-Cookbook, but can we appreciate how brief the documentation is on how to get it done in homebrew?  Looking at the porters handbook for FreeBSD is daunting to say the least. I can't even _find_ the section on how to update a port. 

It's been a long time since I maintained ports, and I've been using FreeBSD since version 4, but the ports system has remained much the same that I can see. I really wonder if something like a homebrew port to FBSD could impact port maintenance in a positive way.


----------



## pyret (Mar 17, 2019)

Then use pkgsrc.


----------



## eydaimon (Mar 17, 2019)

pyret said:


> Then use pkgsrc.



Mainly trying to have a productive conversation about the current port system and how / if it can be improved.


----------



## MarcoB (Mar 17, 2019)

Maybe I'm not understanding the problem here, but if a port isn't up-to-date and the maintainer isn't responding, why not create a patch yourself and submit it to bugzilla?


----------



## Nyakov (Mar 17, 2019)

eydaimon said:


> idea of having _one_ maintainer


It sounds strange.



eydaimon said:


> Looking at the porters handbook for FreeBSD is daunting to say the least. I can't even _find_ the section on how to update a port.


This looks frightening...

I can think about virtual machine image with configured software for ports maintaining...
Perhaps some sort of IDE for this... plugin for Eclipse or something.


----------



## eydaimon (Mar 17, 2019)

MarcoB said:


> Maybe I'm not understanding the problem here, but if a port isn't up-to-date and the maintainer isn't responding, why not create a patch yourself and submit it to bugzilla?



The problem is that I keep coming across ports that take a long time to get updated, or have not been updated in a long time. Was it not clear in my first post ?  I'm just fishing for everyone's opinion about what can be done to address this. I can't keep submitting PR's to every port I come across. The question is how can we  make this process so easy that the ports are kept up to date.


----------



## D-FENS (Mar 17, 2019)

Nyakov said:


> If manpower is the problem, then, does this problem on the main problems list for someone? FreeBSD foundation, Core Team?
> 
> I strongly suspect that it is not.
> If it is so, then what we can do with this?


Issue - ports too old:
One could volunteer as a port maintainer, which would mean keeping a port up to date, compiling and if necessary, patching so that it works on FreeBSD. Porting can be hard work, depending on the ported project.

Issue - ports crash:
Another way to contribute is just be a tester (what we do here) and report issues back to the port maintainers. Collaborate by providing test scenarios that crash, logs, crash dumps. One does not need programming for this.


My personal approach is to test everything latest and greatest that I can. If I encounter any problems, I go to the forum and ask. If it turns out to be a bug, I report it. And if necessary, I write a post on the forum with the solution or workaround. I think this helps a lot!


----------



## xtremae (Mar 17, 2019)

MarcoB said:


> Maybe I'm not understanding the problem here, but if a port isn't up-to-date and the maintainer isn't responding, why not create a patch yourself and submit it to bugzilla?


I can think of a couple of reasons in no particular order: not all users are familiar with port maintenance, those that do face upstream changes that break the build, the new version of the port builds fine but has run-time errors the user can't or doesn't know how to trace and fix, etc.

If there is no policy to flag and deprecate buggy and vulnerable ports, more of them will keep pilling up. Quantity over quality.
From my own experience, if a package doesn't exist, users who need it are willing to port it. If a stale and vulnerable package exists, users will settle for the the path of least resistance and just install it.


----------



## pyret (Mar 17, 2019)

eydaimon said:


> Mainly trying to have a productive conversation about the current port system and how / if it can be improved.


There is no problem.  You're trying to create one that doesn't exist, which isn't productive and just a waste of time.



> The question is how can we  make this process so easy that the ports are kept up to date.


You can't.


----------



## MarcoB (Mar 17, 2019)

xtremae said:


> If there is no policy to flag and deprecate buggy and vulnerable ports, more of them will keep pilling up.


But the ports system has this already.
Point is that users have two options: or contact the maintainer that his port is old or has bugs, or patch it yourself.


----------



## xtremae (Mar 17, 2019)

MarcoB said:


> But the ports system has this already.


I know it does but for some reason they're not being removed.



MarcoB said:


> Point is that users have two options: or contact the maintainer that his port is old or has bugs, or patch it yourself.


As evidenced by the outdated and buggy packages in the ports tree, it is fairly obvious that this doesn't work. Essentially, the above solution is inadequate.


----------



## D-FENS (Mar 17, 2019)

pyret said:


> You can't.


I agree. It depends strongly on the ported software.
If it is programmed with portability in mind and uses only standard UNIX APIs, or if it is Java based for example, it could compile and run without many or any changes on all platforms.
However, if it uses some platform specific features extensively, then porting it can be a full-time job for one or more people. I know from experience.
Anything changes in the generic code and all of a sudden the new version does not work anymore on your platform - you need to debug and fix the bug. And in some aspects it could be harder than writing the software itself, because you need to understand at least two platforms to work effectively.


----------



## eydaimon (Mar 17, 2019)

roccobaroccoSC said:


> I agree. It depends strongly on the ported software.



What I mean is that we should make sure that it's not the process of updating a port in the current port systems that's the bottleneck.  I referenced the ports manual before saying there's not even an obvious section on how to update a port when looking at the table of contents. The whole process is daunting; at least tome.


----------



## D-FENS (Mar 17, 2019)

eydaimon said:


> What I mean is that we should make sure that it's not the process of updating a port in the current port systems that's the bottleneck.  I referenced the ports manual before saying there's not even an obvious section on how to update a port when looking at the table of contents. The whole process is daunting; at least tome.


So if I understand correctly, the issue is insufficient or unclear documentation about how to create and maintain a port? I have not read the ports docu so I don't know how good it is at the moment but one could speak to the ports docu owners about this.
At first glance the docu seems very nice.


----------



## eydaimon (Mar 17, 2019)

roccobaroccoSC said:


> So if I understand correctly, the issue is insufficient or unclear documentation about how to create and maintain a port?



I don't know the cause. I just know I keep running into ports that are old or take weeks/months to be updated. I'm speculating.  There's no way I have time to update every single port I come across. If it's as simple as just tweaking the Makefile to another version, and doing a pull-request, sure. That's not been my experience though.


----------



## D-FENS (Mar 17, 2019)

eydaimon said:


> I don't know the cause. I just know I keep running into ports that are old or take weeks/months to be updated. I'm speculating.  There's no way I have time to update every single port I come across. If it's as simple as just tweaking the Makefile to another version, and doing a pull-request, sure. That's not been my experience though.


Good point! Unless one gets paid, maintenance is a hobby. Few people can afford putting a lot of effort into it. And it comes at no cost to us, so I think even if it's not perfect, it's damn good quality for a free system!
What would motivate well to maintain a port would be in my opinion one of two cases: (1) someone needs it badly for private purposes, maintains the software and shares with the community; (2) a company needs it to do its business, so it sponsors developers to maintain the software (for example, iX Systems and FreeNAS).


----------



## ralphbsz (Mar 18, 2019)

eydaimon said:


> I don't know the cause. I just know I keep running into ports that are old or take weeks/months to be updated.


If you want to use the software from a port, but it has not been maintained (which means that there isn't enough volunteer manpower to maintain it), then you have two choices.  Either take over the work of maintaining / update the port yourself, or don't use that software.  In theory you could try to get volunteers to work harder, or find new volunteers; in practice that doesn't work, so there is no third option: tertium non datur.

You may find that there is a whole lot of packages that are "related" to each other than don't have ports to your satisfaction.  Where "related" might mean that they are solve similar problems, or have similar dependencies.  From the reports it seems  those dependencies are often GUI toolkit things (Qt, GTK, KDE, ...).  Maybe this means that FreeBSD is not suitable for a certain type of user and a certain type of application.



> There's no way I have time to update every single port I come across. If it's as simple as just tweaking the Makefile to another version, and doing a pull-request, sure. That's not been my experience though.



I've only had to compile from ports very few times, perhaps 8 or 10 times in the last ~10 years of using it.  All the rest I install from packages, and they works "perfectly" (and I put perfectly in quotes: sometimes software does exactly what it advertises, and then I find that this is not what I wanted or needed so I delete it again).  For compiling from ports, I've never had to do more than do a pull (or download the source from a commonly known location), adjust the makefile, and compile.  But then, I only use FreeBSD as a server platform (never as a desktop or GUI machine).  I think there is a strong hint in there what type of uses FreeBSD is suitable for.


----------



## drhowarddrfine (Mar 18, 2019)

eydaimon said:


> the ports system has remained much the same that I can see. I really wonder if something like a homebrew port to FBSD could impact port maintenance in a positive way.


Identify the problem you are trying to solve and how Homebrew solves that.


----------



## chrcol (Mar 18, 2019)

What wont be helping maintainers is it seems almost every year the process changes, e.g. the staging process.  Some will likely be doing it with minimum amount of free time, and if they keep having to learn changes they may just give up.


----------



## Deleted member 30996 (Mar 18, 2019)

I used to use Weatherspect on my machines for the ASCII art that went along with the weather forecasts. It stopped working so I contacted the maintainer with shots of the problems.

He replied right away and it was an issue with WeatherUndergound not providing the service for free anymore. It couldn't be fixed and he said it would be removed.

I'm more concerned with multimedia/xmms. It's a dead project upstream and now it won't build due to a dependency issue. I started using it with Linux and is the only audio player I like.



Nyakov said:


> I think this is conceptual problem. Software meant to be used, not to be builded, it is not the purpose of software. *The same is relevant to the OS itself.*



Now you're opening a whole new can of worms.


----------



## Vull (Mar 18, 2019)

It appears kde.org maintains the FreeBSD ports for their own stuff and they've been doing a great job IMO. Good support and an apparently good relationship with FreeBSD are two of the several reasons I picked KDE over other DEs available on FreeBSD. Version 5.15.3 came out Tues, March 12 and the plasma5-plasma port is already up to date; they've been putting out new updates about every week or so.

From another point of view, some consider a slower revision schedule to be a measure of _stability_, and there's a lot of merit in that argument too. It's good to be able to keep using a good stable version of something without worrying so much about keeping up with all the latest updates all the time. Chasing the latest updates is something I associate with Windows and Ubuntu. It's hard to do development when the OS provider keeps pulling the rug out from under you with updates which are too frequent, too untested, and which sometimes can even be completely unanticipated. If software works well and as expected, there's really no need to be in any big hurry to update.


----------



## Nyakov (Mar 18, 2019)

roccobaroccoSC said:


> And it comes at no cost to us, so I think even if it's not perfect, it's damn good quality for a free system!


We all here part of community, not the buyers and not the sellers.
And the cost have nothing to do with quality. Quality can be of any value.
And for user cost can came in other ways.

What can motivate people, is, low entry point, and friendly community.



roccobaroccoSC said:


> : (1) someone needs it badly for private purposes, maintains the software and shares with the community;


Or just installs linux.


----------



## SirDice (Mar 18, 2019)

Nyakov https://forums.freebsd.org/threads/why-is-freebsd-not-more-like.66591/

Thread closed.


----------

