Date: Fri, 12 Feb 2016 07:25:30 -0900 From: Royce Williams <royce@tycho.org> To: Jim Ohlstein <jim@ohlste.in> Cc: John Marino <freebsdml@marino.st>, Kevin Oberman <rkoberman@gmail.com>, lev@freebsd.org, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: ports/pkg/OS integration 2.0 (was: Re: Removing documentation) Message-ID: <CA%2BE3k91JR8Fpax%2BC3Q_kPXpnHrtikKADVqkUWeC1MQJe=PLnnw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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. * 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). * 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). * 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). In other words, the end goal should be that the OS, ports, and packages can coexist for common use cases. Royce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BE3k91JR8Fpax%2BC3Q_kPXpnHrtikKADVqkUWeC1MQJe=PLnnw>