CVS removal from the base
Daniel Eischen
deischen at freebsd.org
Mon Dec 5 13:36:40 UTC 2011
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<julian at 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
More information about the freebsd-current
mailing list