Re: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
On Fri, Feb 12, 2016 at 1:07 PM, Roger Marquis wrote: >>> (The Ubuntu /etc/alternatives symlink system and other mechanisms solve >>> this well) > > > That hasn't been my experience but then I'm not a big fan of symlinks > which can't be safely modified outside of the (d)pkg system. As a > general rule you want to avoid such unnecessary layers of abstraction > where possible. > >>> * 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). > > > Can't really see much use for this. Those of us building from source > know when we can install a binary and nobody really wants to be > held-up by another prompt. That's exactly why I suggested the knobs. I regularly run into circumstances where I want to tweak a config option for one port, but I'd actually prefer that its dependencies be packages ... until I need to tweak something else. So in my pie-in-the-sky world, when an upgrade triggers the need to upgrade a dependency, if the config options haven't changed, then install the package automatically; otherwise, show me the new config options (highlighted!), and ask me if I want to change the defaults. If I do, that dependency becomes managed from ports. If I don't, it stays managed by packages. The knobs would let you make this behavior possible -- or not. It would be nice to be asked at the point of installing the system what kind of software management you want: [X] Install software from binary packages only [ ] Install software from ports only (compiling everything locally) [ ] Prefer packages, prompting me when default options change [ ] Prefer ports, but use packages if the port options are identical Royce ___ 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"
Re: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
(The Ubuntu /etc/alternatives symlink system and other mechanisms solve this well) That hasn't been my experience but then I'm not a big fan of symlinks which can't be safely modified outside of the (d)pkg system. As a general rule you want to avoid such unnecessary layers of abstraction where possible. * 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). Can't really see much use for this. Those of us building from source know when we can install a binary and nobody really wants to be held-up by another prompt. Roger ___ 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"
Re: ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
Hello, On 2/12/16 11:25 AM, Royce Williams wrote: On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams 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"
ports/pkg/OS integration 2.0 (was: Re: Removing documentation)
On Fri, Feb 12, 2016 at 6:38 AM, Royce Williams 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 ___ 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"
