I love FreeBSD: I wish ports were up to date

Status
Not open for further replies.

eydaimon

Active Member

Reaction score: 3
Messages: 102

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

Administrator
Staff member
Administrator
Moderator

Reaction score: 1,230
Messages: 4,079

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

Active Member

Reaction score: 44
Messages: 113

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

Active Member

Reaction score: 75
Messages: 111

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.
 
OP
OP
eydaimon

eydaimon

Active Member

Reaction score: 3
Messages: 102

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

Active Member

Reaction score: 75
Messages: 111

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

Member

Reaction score: 3
Messages: 30

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.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 406

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

Member

Reaction score: 3
Messages: 30

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

Well-Known Member

Reaction score: 119
Messages: 285

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.
 
OP
OP
eydaimon

eydaimon

Active Member

Reaction score: 3
Messages: 102

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.
 

MarcoB

Well-Known Member

Reaction score: 103
Messages: 376

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?
 
OP
OP
eydaimon

eydaimon

Active Member

Reaction score: 3
Messages: 102

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.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 406

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

Member

Reaction score: 13
Messages: 41

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.
 

MarcoB

Well-Known Member

Reaction score: 103
Messages: 376

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

Member

Reaction score: 13
Messages: 41

But the ports system has this already.
I know it does but for some reason they're not being removed.

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.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 406

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.
 
OP
OP
eydaimon

eydaimon

Active Member

Reaction score: 3
Messages: 102

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.
 

roccobaroccoSC

Well-Known Member

Reaction score: 93
Messages: 406

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.
 
OP
OP
eydaimon

eydaimon

Active Member

Reaction score: 3
Messages: 102

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.
 
Status
Not open for further replies.
Top