Date: Fri, 12 Feb 2016 11:54:54 -0500 From: Jim Ohlstein <jim@ohlste.in> To: Royce Williams <royce@tycho.org> Cc: John Marino <freebsdml@marino.st>, Kevin Oberman <rkoberman@gmail.com>, lev@freebsd.org, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: ports/pkg/OS integration 2.0 (was: Re: Removing documentation) Message-ID: <56BE0E5E.7020102@ohlste.in> In-Reply-To: <CA%2BE3k91JR8Fpax%2BC3Q_kPXpnHrtikKADVqkUWeC1MQJe=PLnnw@mail.gmail.com> References: <CA%2BE3k91JR8Fpax%2BC3Q_kPXpnHrtikKADVqkUWeC1MQJe=PLnnw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, On 2/12/16 11:25 AM, Royce Williams wrote: > On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams <royce@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56BE0E5E.7020102>