ports/pkg/OS integration 2.0 (was: Re: Removing documentation)

[Jim Ohlstein]

Hello,

On 2/12/16 11:25 AM, Royce Williams wrote:
> On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams <royce at 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