Ports Tree Philosophy Upgrade Needed

Here's another idea! How about adding a dependencies build flag option to ports? By default, even if not specified, the build option is active and the build process behaves as it always worked. If specified, for example:
Code: 
# cd /usr/ports/x11-fm/xfe
# make dependencies=false install clean
would attempt to build xfe without compiling its dependencies. Obviously, it's not the safest option. But if it works, good! You may save lots of building time, and prevent risks of poisoning already installed ports. With this option, you have the ability to temporarily ignore minor changes to X or Perl if you wish so. It's a Use at your own risk option.

If it doesn't work, you simply revert to the good old:
make install clean
as it's always been done before.

Dominique.
 
fossette said:
Here's another idea! How about adding a dependencies build flag option to ports? By default, even if not specified, the build option is active and the build process behaves as it always worked. If specified, for example:
cd /usr/ports/x11-fm/xfe
make dependencies=false install clean
would attempt to build xfe without compiling its dependencies. Obviously, it's not the safest option. But if it works, good! You may save lots of building time, and prevent risks of poisoning already installed ports. With this option, you have the ability to temporarily ignore minor changes to X or Perl if you wish so. It's a Use at your own risk option.

If it doesn't work, you simply revert to the good old:
make install clean
as it's always been done before.

Dominique.
Click to expand...

What would this accomplish? When you're building from a completely clean state you absolutely must build all the dependencies first or your build will fail. You can't play tricks with the dependencies and start guessing if they are already installed or not. When you build a package of a port the end result can not be different depending on if a dependency was already installed or if it had to be built first.
 
fossette said:
would attempt to build xfe without compiling its dependencies. Obviously, it's not the safest option. But if it works, good! You may save lots of building time, and prevent risks of poisoning already installed ports. With this option, you have the ability to temporarily ignore minor changes to X or Perl if you wish so. It's a Use at your own risk option.
Click to expand...

You would have to test a port's build on your own computer/computer's jail from a clean port's tree, or know of a valid replacement for a port to then suggest it. Then it moves on to developer's territory, usually shell scripting and C programming language which is another thread and forum.
 
Not sure if I can still add anything useful to this post. Hope you won't blame for arriving late.
I think the endemic problem of dependency hell will somehow probe to be a limiting factor for growth in the *NIX world. Linux is also ill with this epidemic situation.

I think we need to retake the PBI model. FreeBSD shines because base system and ports are separated, so there are no reasons to not try again, and this time with success. I am more than happy to help to rearchitect the ports system based on nPBI (new PBI) model, if somebody has the patience to sit with me and explain the roadblocks we faced with PBI.
 
FreeBSD's port's dependency problem has made major improvements this year.

One thing that can be done, is make ports depend primarily depend on BSD solutions like audio/oss or sqlite. If there is a feature these lack, let it pull down a version of a program such as audio/alsa, that is usually trimmed to only include the features that are missing, such as from OSS or a database. Doing this dependency-wise would be most practical. Doing more, would require major changes to sourcecode, and that would be incompatible with how the ports are downloaded, or it would take the compilation process knowing what to omit to achieve this.

For a while I was eager to see sysutils/hal replaced with devd(8) in the ports tree as the default option, except for newly ported programs, but they seem to coexist together without conflicting. These two programs coexisting seem ok.
 
You must log in or register to reply here.
Back
Top