Hello,

On 2/12/16 11:25 AM, Royce Williams wrote:
On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams <ro...@tycho.org> wrote:
This is, indeed, a gap in the Debian world.  It's one that the ports
system is a great start towards resolving.  That's why I think that
ports + pkg could be a superior offering that people would flock to,
and which deserves more focus.

To be fair, this is also why my comparison FreeBSD's ports system to
some other OSes binary package system is an unfair comparison.  :)
The complexity of letting people pick their own compilation options is
significant, and one that the Linux/Debian/dpkg world largely
sidesteps.

But it's exactly where I think that FreeBSD could really shine.
FreeBSD's ports system is the best system I've seen for managing
custom compilation.  If the OS, binary packages, and ports were more
tightly integrated, it would be magic.

Some goals:

* The OS needs a structured way to know that a different package has
changed its default behavior in some way.  (The Ubuntu
/etc/alternatives symlink system and other mechanisms solve this
well). In other words, a common framework that could accommodate
things like deciding to use a port or package instead of the facility
provided by the OS.

This is true. That probably would not be impossible to implement. It would be nice to be able to have two or more versions of a tool installed and relatively seamlessly switchable, at least for testing. I'm thinking PHP, Apache, nginx, etc.

/usr/local/bin/php5 and /usrlocal/bin/php7 with one at any time symlinked to /usr/local/bin/php or /usr/local/alternatives/php or whatever.


* Port maintainers should be able to express how one-offs and
conflicts should be resolved in a machine-readable way. (In other
words, as a test of fitness to purpose, most historic entries in
/usr/ports/UPDATING should be programmatically expressible in the
system).

Yes!


* The ports system needs to know which compilation options were used
by packages in the pkg system, so that if a conflict arises, it can be
intelligently expressed by the maintainers (or the user can be told
that they are mutually exclusive).

I believe at this time all official packages are compiled with the particular port's default options. That is until "flavors" are implemented at some point in the future.


* if the user's port configuration options aren't different from the
package defaults, ask the user if they want to use the package instead
(with global and per-port knobs to stop asking if the user desires).

Another big YES!


In other words, the end goal should be that the OS, ports, and
packages can coexist for common use cases.


--
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Reply via email to