On Mon, 5 Dec 2011, Julian Elischer wrote:
On 12/4/11 9:21 PM, Daniel Eischen wrote:
On Dec 4, 2011, at 7:42 PM, Julian Elischer<jul...@freebsd.org> wrote:
On 12/4/11 3:36 PM, Randy Bush wrote:
This seems too reasonable a suggestion, but, as always, the devil
is in the details. There will be long. painful discussions (and
arguments) about what to remove from the base to the new structure
and what things currently NOT in the base should be promoted.
as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is
tempting. but, as you hint, is this not just doubling the number of
borders over which we can argue?
but let's get concrete here.
i suspect that my install pattern is similar to others
o custom install so i can split filesystems the way i prefer,
enabling net& ssh
o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer
if it does not have emacs)
o hack /etc/ssh/sshd_conf to allow root with password
o rsync over ~root
o hack /etc/ssh/sshd_conf to allow root only without-password
o rsync over my standard /etc/foo (incl make.conf and src.conf)
and other gunk
o csup releng_X kernel, world, doc, ports
o build and install kernel and world
and then do whatever is special for this particular system.
anything which would lessen/simplify the above would be much
appreciated. anything not totally obiously wonderful which would
increase/complicate the above would not be appreciated.
my suggestion is that the 'sysports' or 'foundation ports' or
'basic ports', (or whatever you want to call them) in their package
form come with the standard install in fact I'd suggest that they
get installed into some directory by default so that 'enabling' them
ata later time doesn't even have to fetch them to do the pkg_add.
They have pre-installed entries in /etc/defaults/rc.conf. and only their
rc,d
files need to beinstalled into /etc along with their program files.
They are as close to being as they are now with the exception of
being installed in the final step instead of at the same time as the rest
of the stuff,
and it allows them to easily be 'deinstalled' and replaced by newer
versions.
I really don't understand how this is much different than having them exist
in base. We have WITHOU_foo (I don't really care if that were to become
WITH_foo if we want to default to a more minimum system), so one can always
use ports if they want some different version of foo. And it's not just
releases we care about, we want a stable foo (BIND for example) with
security and bug fixes throughout all updates to -stable, not just at
releases.
I want to do one buildworld and have a complete and integrated system. I
don't see how having a separate repo for sysports helps; it is yet another
thing I have to track. And are ports in sysports going to default to being
installed in / or /usr/local?
I think there are several differences..
1/ The ability to UNINSTALL it and replace it completely with a differnet
version
If we go to a complete pkg-based system, then there is no difference
here, so why not do that?
2/ allow easy leave-out feature.. leaving it out is less risky..
WITH_FOO/WITHOUT_FOO vs pkg_delete, not sure there is much
of a difference. The advantage of WITH/WITHOUT is that the
system is built as a whole and integrated. src/ developers
are suppose to not break src/; they may not be so inclined
to worry about sysports. Will emphasis be put on src/ developers
to include sysports in their "buildworld" and will tinderboxes
also include sysports?
3/ probably the most important.. allowing both ports and src developers to
work on the packages.
Give ports maintainers that maintain BIND, FOO, access
to src/ (which they probably have already).
4/ allowing us to promote some of the commonly used packages to a more
supported level without actually bringing them into the base system.
--
DE
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
