Ports May Benefit From Increased Robustness of Scripts

Yesterday, I tried to install the nv, vesa, and nvidia drivers for my kernel.

The nvidia kernel driver complains about lack of sources. After I installed the sources, I was able to get the x11/nvidia-driver to compile.

The Ports system in my opinion, is somewhat primitive. It can handle dependencies, but, if the dependency is a configuration option, like I mentioned above, then the build will fail until the dependency is met manually by the user. A solution to that would be to run more advanced scripts to install the dependencies.

There is not much leeway in terms of variances and nuances that the Ports System can manage. An install script ran as a reaction to me doing make in x11/nvidia-driver, but the make failed due to a pre-requisite that arose from me selecting support for linux-compat (for the nvidia driver) and other things the config script in the port asked me.

I think that ports scripts should do more work than they currently do? I recommend some high-level, high-powered scripting language like PERL to wrangle the packages' run-time dependencies in addition to the regular dependencies system in place such as pkg_add -r packagename or cd ports/port_cat/someport/ && make. With the use of PERL, we can have a more inviting, capable, and robust package management system.
 
The problem isn't clear, but it doesn't sound quite like a port system problem so much as a problem with a particular port or usage of that port. Can't tell without more specifics.
 
gordon@ said:
Do you have a degree in marketing?

Ah ha, No gordon I do not have a degree in marketing, but I am indeed trying to sell my point here. My point being, I want the port package scripts to do more of the configuration for me. I can do it, but when installing packages on the fly, it adds lag until you can get to using the binary on the system.

Open source and free-software communities have a bad habit of attacking people who raise critical points, even though they might have a solution. I am learning PERL now, and I just recommended that language due to its inherent context heaviness: that attribute will keep the less experienced and thorough coders away from the ports system, an advantage that can be had for little to no cost.
 
eldersnake said:
Doesn't the current system more conform to the more simple text file configurations of BSD?

The text file configuration can stay, on Penguin systems, APT and RPM use text configuration files. Those two package management systems are highly robust. I don't know what the PBI files use on PC-BSD.

Text configuration files are a must I think. So I don't think they will be thrown out with the bath water if we add some more pazazz to the Ports System package scripts.

I just want my life in FreeBSD to be easier. Is that a crime?
 
if you set the ports options using something like 'make config', then it will cause the port to require the extra dependency and will complain about it not being met *before* actually attempting to compile the distfile.

This seems robust to me.

If you wanted to get a list of all dependencies (i.e to download before going to an offline machine) then make sure to run 'make config' first before listing the dependencies.

Whilst I would like to see work on the ports system (i.e making a package as a non root user and/or adding autogenerated pkg-plist) I have not yet experienced the problems you have described. (Usually because I use the option -DBATCH)
 
We can't use perl for this because it's not in the base (anymore). Keep in mind that the standard pkg_tools need to run on a standard base system without requiring additional components.
 
lockfile said:
Open source and free-software communities have a bad habit of attacking people who raise critical points, even though they might have a solution.
They also have a bad habit of getting annoyed when code bases with a decade long of evolution and maturity are trivialized by those with near zero understanding of the complexity of the task.

When you have a patch to contribute, I'm sure they'll be all ears.
 
Back
Top