Re: CVS removal from the base
From: Doug Barton do...@freebsd.org Having things in ports doesn't make them less available. :) From Julian H. Stacey j...@berklix.com It didn't used to. It risks it now, since in last months, some ports/ have been targeted by a few rogue commiters purging, who want to toss ports out from one release to another without warning of a DEPRECATED= in previous release Makefiles. From: Julian Elischer jul...@freebsd.org which brings up teh possibility of 1st class ports.. which are kept more as part of the system.. (sorry for sounding like a broken record..) Interesting idea, to bounce the idea around a bit: It would extend the spectrum to /usr/src/ ..Most.. /usr/src/ contrib 1st class ports ... in src or ports or elsewhere ? ... (if elsewhere, work to reconfig mirrors to. doc new struct later) /usr/ports currently 22906 An empty current ports tree takes 485 M ( a lot of inodes which occasionaly trips people). A current src tree takes 705 M Ports has lots of commiters Src has less partly different commiters stricter watched more release aligned. Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. EU tax to kill London Vetoed http://berklix.com/~jhs/blog/2011_12_11 ___ 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
Re: CVS removal from the base
On Wed, Dec 14, 2011 at 2:00 PM, Julian H. Stacey j...@berklix.com wrote: Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. NetBSD's pkgsrc is already cross-OS (kind of), but it contains fewer ports than FreeBSD's ports collection: http://www.netbsd.org/docs/software/packages.html Cheers, Julian -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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
Re: CVS removal from the base
There is also mirports from MirBSD that is supported on MirBSD, MidnightBSD, and Mac OS X. They also got a pkgsrc port going recently. The problem is that projects have specific needs that other systems don't have. FreeBSD ports are by far the largest and very fast to build. Pkgsrc comes out quarterly so it takes a long time to get patches in or updates as Dragonfly goes through. With MidnightBSD, we wanted all ports to go through fake install so our packages would work all the time and we could write package tools customized for the ports tree. Every BSD has different needs and different users. Lucas Holt On Dec 14, 2011, at 10:07 AM, C. P. Ghost cpgh...@cordula.ws wrote: On Wed, Dec 14, 2011 at 2:00 PM, Julian H. Stacey j...@berklix.com wrote: Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. NetBSD's pkgsrc is already cross-OS (kind of), but it contains fewer ports than FreeBSD's ports collection: http://www.netbsd.org/docs/software/packages.html Cheers, Julian -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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 ___ 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
Re: CVS removal from the base
Lucas Holt l...@foolishgames.com writes: There is also mirports from MirBSD that is supported on MirBSD, MidnightBSD, and Mac OS X. They also got a pkgsrc port going recently. The problem is that projects have specific needs that other systems don't have. FreeBSD ports are by far the largest and very fast to build. Pkgsrc comes out quarterly so it takes a long time to get patches in or updates as Dragonfly goes through. With MidnightBSD, we wanted all ports to go through fake install so our packages would work all the time and we could write package tools customized for the ports tree. Every BSD has different needs and different users. You can use pkgsrc-current, which is updated all the time. It also supports installation to fake DESTDIR, from where binary packages are made and then installed. It is useful, if you are building as unprivileged user. And pkgsrc already supports FreeBSD. Lucas Holt On Dec 14, 2011, at 10:07 AM, C. P. Ghost cpgh...@cordula.ws wrote: On Wed, Dec 14, 2011 at 2:00 PM, Julian H. Stacey j...@berklix.com wrote: Maybe sometime we will see a project arise that will be a replacement ports/ for more than one BSD, perhaps even extending to Linux, (to avoid reinventing of the wheel that must go on with ports skeletal structs for each OS) ( maybe with an RFC for a port/ skeleton struct ? If so, that may have ramifications on bits of src moved to ports. NetBSD's pkgsrc is already cross-OS (kind of), but it contains fewer ports than FreeBSD's ports collection: http://www.netbsd.org/docs/software/packages.html Cheers, Julian -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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 ___ 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 -- Daniel Horecki http://morr.pl http://linux.pl http://netbsd.pl http://netbsd.org HAIL ERIS! BOFH since 1999. ___ 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
Re: CVS removal from the base
On Wed, Dec 14, 2011 at 05:31:15PM +0100, Daniel Horecki wrote: Lucas Holt l...@foolishgames.com writes: There is also mirports from MirBSD that is supported on MirBSD, MidnightBSD, and Mac OS X. They also got a pkgsrc port going recently. The problem is that projects have specific needs that other systems don't have. FreeBSD ports are by far the largest and very fast to build. Pkgsrc comes out quarterly so it takes a long time to get patches in or updates as Dragonfly goes through. With MidnightBSD, we wanted all ports to go through fake install so our packages would work all the time and we could write package tools customized for the ports tree. Every BSD has different needs and different users. You can use pkgsrc-current, which is updated all the time. It also supports installation to fake DESTDIR, from where binary packages are made and then installed. It is useful, if you are building as unprivileged user. And pkgsrc already supports FreeBSD. What you are pointing here: fake DESTDIR, binary packages and building as unpriviledged, are fairly easy to add to FreeBSD, I'm working on all this. it is not complicated, but it takes a lot of time, no need to go elsewhere to get those features, the ports tree is almost able to handle it. regards, Bapt pgpG5JpqeJjOI.pgp Description: PGP signature
Re: CVS removal from the base
On 12/11/2011 06:14, Julian H. Stacey wrote: Doug Barton wrote: On 12/02/2011 04:35, Adrian Chadd wrote: I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. BSD is more conservative. More value given to stability of availability of interfaces tools etc, Having things in ports doesn't make them less available. :) More Long term professionals. I don't know what this means. Doug's attempting to force working FreeBSD ports such as procmail to be discarded is deplorable. Um, I had nothing to say about procmail. In fact, I use procmail, and would not want to see it removed. Doug should stop coercing FreeBSD toward a Linux model, move himself to Linux. I actually do use Linux sometimes. In many ways it is a far superior desktop. That said, I am certainly *not* trying to turn FreeBSD into another Linux distro. What I am trying to do is to see what we can learn from how Linux does things, and apply those ideas here when they are useful. Just because Linux does it, doesn't mean it's wrong. :) I've said this before, but it's worth repeating. Decisions that were made 20 years ago about what should and should not be included in the Berkeley Software Distribution, while valid at the time, may not be valid any longer because things have changed since then. Just to take one obvious example, when these decisions were being made it was necessary to distribute a full system, including the 3rd party stuff, all in one go because the software was being distributed on magnetic tape. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: CVS removal from the base
Hi, Reference: From: Doug Barton do...@freebsd.org Date: Tue, 13 Dec 2011 13:29:02 -0800 Message-id: 4ee7c39e.6040...@freebsd.org Doug Barton wrote: On 12/11/2011 06:14, Julian H. Stacey wrote: Doug Barton wrote: On 12/02/2011 04:35, Adrian Chadd wrote: I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. BSD is more conservative. More value given to stability of availability of interfaces tools etc, Having things in ports doesn't make them less available. :) It didn't used to. It risks it now, since in last months, some ports/ have been targeted by a few rogue commiters purging, who want to toss ports out from one release to another without warning of a DEPRECATED= in previous release Makefiles. More Long term professionals. I don't know what this means. Older folk with more decades of Unix are likely to have had BSD experience way back , jumped at BSD when eg BSD Lite 386BSD came out. Younger folk may have a higher chance their first Unix exposure was Linux on a CD from a computer mag. some of each will have stayed with the BSD or Linux they started with. Hence BSD people tend to have been working a bit longer I think. Doug's attempting to force working FreeBSD ports such as procmail to be discarded is deplorable. Um, I had nothing to say about procmail. In fact, I use procmail, and would not want to see it removed. Doug should stop coercing FreeBSD toward a Linux model, move himself to Linux. Whoops ! _Apologies_ Doug ! I was mixing people up. Apologies ! I actually do use Linux sometimes. In many ways it is a far superior desktop. That said, I am certainly *not* trying to turn FreeBSD into another Linux distro. What I am trying to do is to see what we can learn from how Linux does things, and apply those ideas here when they are useful. Just because Linux does it, doesn't mean it's wrong. :) Yup, each distro can have some good bad. I've said this before, but it's worth repeating. Decisions that were made 20 years ago about what should and should not be included in the Berkeley Software Distribution, while valid at the time, may not be valid any longer because things have changed since then. Just to take one obvious example, when these decisions were being made it was necessary to distribute a full system, including the 3rd party stuff, all in one go because the software was being distributed on magnetic tape. Good point. Doug Apologies again for confusing your name with others. FYI URLs to end of 1st procmail thread beginning of 2nd http://docs.freebsd.org/cgi/getmsg.cgi?fetch=948124+0+archive/2011/freebsd-ports/20110904.freebsd-ports http://docs.freebsd.org/cgi/getmsg.cgi?fetch=85459+0+/usr/local/www/db/text/2011/freebsd-ports/20111002.freebsd-ports Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. EU tax to kill London Vetoed http://berklix.com/~jhs/blog/2011_12_11 ___ 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
Re: CVS removal from the base
On 12/13/11 7:49 PM, Julian H. Stacey wrote: Hi, Reference: From: Doug Bartondo...@freebsd.org Date: Tue, 13 Dec 2011 13:29:02 -0800 Message-id: 4ee7c39e.6040...@freebsd.org Doug Barton wrote: On 12/11/2011 06:14, Julian H. Stacey wrote: Doug Barton wrote: On 12/02/2011 04:35, Adrian Chadd wrote: I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. BSD is more conservative. More value given to stability of availability of interfaces tools etc, Having things in ports doesn't make them less available. :) It didn't used to. It risks it now, since in last months, some ports/ have been targeted by a few rogue commiters purging, who want to toss ports out from one release to another without warning of a DEPRECATED= in previous release Makefiles. which brings up teh possibility of 1st class ports.. which are kept more as part of the system.. (sorry for sounding like a broken record..) ___ 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
Re: CVS removal from the base
On Tue, Dec 13, 2011 at 9:29 PM, Julian Elischer jul...@freebsd.org wrote: On 12/13/11 7:49 PM, Julian H. Stacey wrote: which brings up teh possibility of 1st class ports.. which are kept more as part of the system.. (sorry for sounding like a broken record..) *jumps back into the fray* If it's something that isn't maintainable, because the upstream package is too hard to follow across a major version release cycle, it should be pulled from base. Otherwise, I'd say carry on as usual. Otherwise, there really isn't any difference in package organization from Linux; granted, I would still like to see granular definitions in packaging metadata so one could pick and choose between base and ports openssh for instance, but that's still a nicety that hasn't come true. Thanks, -Garrett ___ 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
Re: CVS removal from the base
Doug Barton wrote: On 12/02/2011 04:35, Adrian Chadd wrote: I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. BSD is more conservative. More value given to stability of availability of interfaces tools etc, More Long term professionals. Doug's attempting to force working FreeBSD ports such as procmail to be discarded is deplorable. Doug should stop coercing FreeBSD toward a Linux model, move himself to Linux. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ 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
Re: CVS removal from the base
On Sat, Dec 3, 2011 at 8:03 PM, sth...@nethelp.no wrote: I use CVS (or rather csup) to keep the base system up to date. I would be perfectly okay with using a different utility - however, I would strongly prefer that this utility was included in the base system. CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. Max I use CVS I've used sup, (maybe csup can't rememeber, not used cvsup really) I avoid reliance on a net connection just to do a checkout. I use ctm to [push] feed my local CVS tree. ctm deltas of cvs src ports are generated [by cvsup, pulling from freebsd.org] elsewhere, ctm-us...@freebsd.org led by Stephen M recently included: Subject: ctm for svn Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ 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
Re: CVS removal from the base
Pedro F. Giffuni wrote: Hi Daniel; --- On Sat, 12/3/11, Daniel Eischen deisc...@freebsd.org wrote: ... I would love to mirror the SVN repo in the same way and have an 'svn' in base, or at least something that could replace CVS in the above scenario. I have to say I am surprised by all the people that still use CVS (for their own good reasons). It still would be helpful if cvs users could evaluate OpenCVS: it's been experimental for ages now. It does seem to have some advantage (other than the license) in that it's smaller and better maintained (or at least not too dead). Did you test it with cd /usr/src/release ; make release Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ 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
Re: CVS removal from the base
--- Dom 11/12/11, Julian H. Stacey j...@berklix.com ha scritto: ... I have to say I am surprised by all the people that still use CVS (for their own good reasons). It still would be helpful if cvs users could evaluate OpenCVS: it's been experimental for ages now. It does seem to have some advantage (other than the license) in that it's smaller and better maintained (or at least not too dead). Did you test it with cd /usr/src/release ; make release TBH, I don't use CVS at all. I learned to use SVN first and for the things I needed CVS was pretty similar to SVN but pretty obnoxious when trying to check out the history due to the lack of atomic commits. I would prefer to just use the same SVN server for everything. OpenCVS is an intermediate step, at least acceptable for GPL cleaning purposes, for people that just can't move to SVN right away. Still SVN is much better and once we move we will not look back (IMHO). Pedro. ___ 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
Re: CVS removal from the base
On 12/11/11 08:39, Julian H. Stacey wrote: Pedro F. Giffuni wrote: Hi Daniel; --- On Sat, 12/3/11, Daniel Eischendeisc...@freebsd.org wrote: ... I would love to mirror the SVN repo in the same way and have an 'svn' in base, or at least something that could replace CVS in the above scenario. I have to say I am surprised by all the people that still use CVS (for their own good reasons). It still would be helpful if cvs users could evaluate OpenCVS: it's been experimental for ages now. It does seem to have some advantage (other than the license) in that it's smaller and better maintained (or at least not too dead). Did you test it with cd /usr/src/release ; make release Cheers, Julian For whatever it's worth, release(7) uses svn for src by default these days. -Nathan ___ 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
Re: CVS removal from the base
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/12/2011 14:30, Julian H. Stacey wrote: On Sat, Dec 3, 2011 at 8:03 PM, sth...@nethelp.no wrote: I use CVS (or rather csup) to keep the base system up to date. I would be perfectly okay with using a different utility - however, I would strongly prefer that this utility was included in the base system. CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. Max I use CVS I've used sup, (maybe csup can't rememeber, not used cvsup really) I avoid reliance on a net connection just to do a checkout. I use ctm to [push] feed my local CVS tree. ctm deltas of cvs src ports are generated [by cvsup, pulling from freebsd.org] elsewhere, ctm-us...@freebsd.org led by Stephen M recently included: Subject: ctm for svn csup will work fine with a local cvs tree and is much (much much) faster than cvs for a sparse checkout. Just run cvsupd locally (does require net/cvsup installed). Chris -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO5OY2AAoJELCEktHh68rEfMYIALDLqMQna7Vkphzk7qVoAIy9 N7iSNoSjS2mrXs841G1k5bxlfyEUN/whAuO3N7PxqXVZ5zTaoNycSSZUsGRNUK+p oFOvy1R7Zsf791++eHUpGk7VYVZeGr5vGwMrM7MyrfLbDawRxp9DGVMJpElGyqBH iMZxq2jZ/HsRxPi8wtuDHuewQX6f+MZg8yODsuio+aReGjwmjPZMTcStt14DfoEi AajHbbdLqMoVEa02N46JcPjDlgWkQ9x0g9cbIxzMoLGIRI7PAmq2sEVNlNIIZYxA vgNQq+qF7D10pg03WpwA54EglWaFhZDk3kYuk57oW94Iayr79PRdKst8wEQVe+4= =ZGlO -END PGP SIGNATURE- ___ 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
Re: CVS removal from the base
On 12/3/11 5:45 PM, Garrett Cooper wrote: Just to back up that point: until CVS is completely unused by releng (docs, ports are still done via CVS), Ah - I am indeed mistaken. Not all that surprising. it really shouldn't be removed from base (no matter how broken or undeveloped it is). I agree. Please forgive the noise coming from my (grey) bikeshed. -- Sean M. Collins ___ 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
Re: CVS removal from the base
On 12/4/11 9:21 PM, Daniel Eischen wrote:
On Dec 4, 2011, at 7:42 PM, Julian Elischerjul...@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
2/ allow easy leave-out feature.. leaving it out is less risky..
3/ probably the most important.. allowing both ports and src
developers to work on the packages.
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
Re: CVS removal from the base
On Sat, Dec 3, 2011 at 3:24 PM, Max Khon f...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. In my mind, a first step would be to move ports to subversion, initially using svn-cvs bridge. Once done, the next step would be to change all infrastructure scripts so that they can build from/be driven by subversion. After that, nothing in base would use cvs for any purpose, and at that point I would be happy for it to be dropped from base - but only if it was replaced by subversion. I think it is important that with a base install of FreeBSD you can check out and update the source and rebuild itself. Cheers Tom ___ 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
Re: CVS removal from the base
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 Elischerjul...@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
Re: CVS removal from the base
Replying to a random message in this thread On 12/05/2011 13:49, Tom Evans wrote: On Sat, Dec 3, 2011 at 3:24 PM, Max Khonf...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. In my mind, a first step would be to move ports to subversion, initially using svn-cvs bridge. Once done, the next step would be to change all infrastructure scripts so that they can build from/be driven by subversion. After that, nothing in base would use cvs for any purpose, and at that point I would be happy for it to be dropped from base - but only if it was replaced by subversion. I think it is important that with a base install of FreeBSD you can check out and update the source and rebuild itself. Cheers Tom 1. I wonder why nobody has raised the point of the existence of numerous cvs/cvsup mirrors for FreeBSD. Do you want all of them to migrate to subversion ? have you asked their opinion about it ? are you prepared to an increased load on fewer servers if they do not migrate ? or are you thinking that this is a non problem because the declining number of users as FreeBSD become a system for the developpers by the developpers and only the developpers ? 2. All these talks about moving things from base to ports / spliting base / creating a new kind of ports miss the point that things must be maintained on an increasing number of branches: with the new 9.0 release there will be 3 stable branches (7.X, 8.X, 9.X), and with the foolish rush to create new major releases this will be ever increasing. But perhaps the real intent is to drop support of some parts of the system before officially stopping the support of a base branch ? 3. Some months ago dougb@ sent a message on a list with the lietmotiv change is difficult. I wonder if he thought about the fact that could be the main reason why people stick to FreeBSD instead of migrating to another more fashionable system. Ordinary users also are volunteers, and in my work experience, using FreeBSD may be a day by day political fight. 4. Do not piss users off by making changes for the sake of it. Do not use your energy to destroy things rather that making things work (but it is easier to destroy that to build). Do not try to impose your view about the use of the system (someone wrote FreeBSD is about tools and not about policies and that must be preserved). I stop here, this message becoming too long and off topic. But I needed to write it in view of the current (sad) evolution of this system /community. Claude Buisson FreeBSD user since 1995 ___ 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
Re: CVS removal from the base
.. they'll work the same way things w/ src work at the moment, which I believe is: * stuff is in svn; * svn2cvs runs; * cvsup mirrors the cvs repository; * users use cvsup against that. So this is a non-issue. :) Adrian ___ 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
Re: CVS removal from the base
On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert freebsd-current-lo...@be-well.ilk.org wrote: Tom Evans tevans...@googlemail.com writes: On Sat, Dec 3, 2011 at 3:24 PM, Max Khon f...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. Max Khon was the one who posted the original message in the thread. That message explicitly stated that moving ports and doc away from CVS was a prerequisite for removing CVS from base. As far as I've noticed, no one has challenged that. I'm trying to think of a way to fit the previous paragraph into the bikeshed metaphor, but I'm coming up with nothing. The bikeshed is discussing about how cvs will eventually be removed from base when there are known, unsolved, issues that block that happening. Removing CVS will be an emotive issue, there is no need to discuss it until appropriate, as every one (like me) will wade in saying that x is good and must stay and x is bad and must die, and every colour of bike shed in between. Just look at the number of replies to this topic. It would be much better to concentrate on the other issues rather than animated discussion of something that cannot realistically happen for quite some time yet. Cheers Tom ___ 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
Re: CVS removal from the base
Tom Evans tevans...@googlemail.com writes: On Sat, Dec 3, 2011 at 3:24 PM, Max Khon f...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. Max Khon was the one who posted the original message in the thread. That message explicitly stated that moving ports and doc away from CVS was a prerequisite for removing CVS from base. As far as I've noticed, no one has challenged that. I'm trying to think of a way to fit the previous paragraph into the bikeshed metaphor, but I'm coming up with nothing. ___ 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
Re: CVS removal from the base
On 12/05/2011 16:28, Tom Evans wrote: On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert freebsd-current-lo...@be-well.ilk.org wrote: Tom Evanstevans...@googlemail.com writes: On Sat, Dec 3, 2011 at 3:24 PM, Max Khonf...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. Max Khon was the one who posted the original message in the thread. That message explicitly stated that moving ports and doc away from CVS was a prerequisite for removing CVS from base. As far as I've noticed, no one has challenged that. I'm trying to think of a way to fit the previous paragraph into the bikeshed metaphor, but I'm coming up with nothing. The bikeshed is discussing about how cvs will eventually be removed from base when there are known, unsolved, issues that block that happening. Removing CVS will be an emotive issue, there is no need to discuss it until appropriate, as every one (like me) will wade in saying that x is good and must stay and x is bad and must die, and every colour of bike shed in between. Just look at the number of replies to this topic. It would be much better to concentrate on the other issues rather than animated discussion of something that cannot realistically happen for quite some time yet. This could have been more clear, and the bikeshed could be stopped soooner, if it had been written before in an authoritative form, and by those who are at the start of this unrealistic proposal. Cheers Tom Claude Buisson ___ 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
Re: CVS removal from the base
On Dec 5, 2011, at 7:57 AM, Claude Buisson clbuis...@orange.fr wrote: On 12/05/2011 16:28, Tom Evans wrote: On Mon, Dec 5, 2011 at 3:12 PM, Lowell Gilbert freebsd-current-lo...@be-well.ilk.org wrote: Tom Evanstevans...@googlemail.com writes: On Sat, Dec 3, 2011 at 3:24 PM, Max Khonf...@samodelkin.net wrote: CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. I wasn't going to jump onto this bikeshed, as CVS will not be going anywhere any time soon, I am sure. I use cvs, rather than csup. I use cvsup to fetch CVS archives to /home/ncvs, and check out ports from there, as described in development(7). If ports were no longer delivered via CVS, you may have had a point about removing CVS from base - but they are not. Max Khon was the one who posted the original message in the thread. That message explicitly stated that moving ports and doc away from CVS was a prerequisite for removing CVS from base. As far as I've noticed, no one has challenged that. I'm trying to think of a way to fit the previous paragraph into the bikeshed metaphor, but I'm coming up with nothing. The bikeshed is discussing about how cvs will eventually be removed from base when there are known, unsolved, issues that block that happening. Removing CVS will be an emotive issue, there is no need to discuss it until appropriate, as every one (like me) will wade in saying that x is good and must stay and x is bad and must die, and every colour of bike shed in between. Just look at the number of replies to this topic. It would be much better to concentrate on the other issues rather than animated discussion of something that cannot realistically happen for quite some time yet. This could have been more clear, and the bikeshed could be stopped soooner, if it had been written before in an authoritative form, and by those who are at the start of this unrealistic proposal. This proposal might have been better for arch for a first pass. I know there are active efforts in progress by the community to move docs and ports over to svn, but I'm not sure what the progress is. Thanks, -Garrett ___ 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
Re: CVS removal from the base
I want to ask some serious questions here, because I genuinely want to understand your thought process. 1. Do you install *any* ports/packages on a new system before you update the source? Answering just for myself here... Going back a bit, in many cases I didn't need to install any packages. Nowadays as a minimum I install Perl. 2. If so, why is installing one more unthinkable? It's not unthinkable. However, IMHO we're then gradually edging closer to various Linux distros that need lots of packages installed to do anything useful. And that, of course, brings up the question - why not just use Linux in the first place? For me, having FreeBSD as a self contained system with lots of useful functionality in the base system is one of the main reasons why I use FreeBSD. 3. Why is it a problem if the port/package you need to install in the early stages has dependencies? For me the dependency on other ports/packages, in itself, is not really a problem. I am much more worried about the fact that a FreeBSD release corresponds to one particular point in time, while the ports collection moves on - and that we'll end up with a FreeBSD release which is broken with the existing ports collection (but works with an earlier version). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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
Re: CVS removal from the base
From Mehmet Erol Sanliturk m.e.sanlit...@gmail.com: Supplying only a console-mode FreeBSD as a release is making FreeBSD unusable for peoples who they are not computing experts . To allow less experienced people to use FreeBSD easily , it is necessary to include a selected ports/packages into release distributions , therefore into so-called BASE as a /ports or /packages part . When a new FreeBSD release will be installed , it is becoming necessary to install many packages additionally , and setting many parameters in the *.conf , etc. , files to make it usable . One unfortunate situation is that some packages are NOT working at the release moment . In the packages tree , it seems that there is no any regular update policy for a specific release . It is possible to make port_name , but this is NOT so much usable also : For a specific package , which is installing within less than 30 minutes by pkg_add , required more than eighteen hours by make ... . Reason was that MAKE is an extremely STUPID system ( without BRAIN ) because , it is NOT able to remember that it has completed making a package part a few seconds before , and it is starting the same steps to apply up to the point that it is not necessary to make it once more ( after applying many steps which was applied before ) . On an old computer with 256 MB RAM, or less, building some of the bigger ports can take many hours. I never dared attempt to build KDE or GNOME! But I don't think PC-BSD runs with 256 MB RAM. In the recent past, FreeBSD releases offered extra iso images with packages, sysinstall even offered to install packages. I tried that once, with FreeBSD 7.0, or was it 7.1 or 6.2, and didn't really get a workable system. GNOME and KDE didn't work. When I tried portupgrading, I messed everything, went back to Linux (Slackware), and when FreeBSD 8.0 was released, cleaned out my old installation, and installed FreeBSD 8.0 fresh. Now, on a new computer, I still use icewm, haven't attempted KDE or GNOME yet. Tom ___ 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
Re: CVS removal from the base
On 04/12/2011 09:08, sth...@nethelp.no wrote: It's not unthinkable. However, IMHO we're then gradually edging closer to various Linux distros that need lots of packages installed to do anything useful. And that, of course, brings up the question - why not just use Linux in the first place? For me, having FreeBSD as a self contained system with lots of useful functionality in the base system is one of the main reasons why I use FreeBSD. +1 -- Bruce ___ 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
Re: CVS removal from the base
Doug Barton wrote: On 12/3/2011 1:21 AM, Roman Kurakin wrote: Doug Barton wrote: [...] The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. You realize that you just 100% demonstrated the truth of what I wrote above, right? :) Don't you really think that one would protect smth that he/she not using? I hope no ;-) People (and me one of them) just try to protect smth they like in a system and they use. If you are ready to provide alternative the number of people against this change will decrease to smaller list that don't like change habits or use smth in much wider area. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. I want to ask some serious questions here, because I genuinely want to understand your thought process. 1. Do you install *any* ports/packages on a new system before you update the source? No. Usually base system is updated in a first turn. I even do not install pkgs usually. 2. If so, why is installing one more unthinkable? Sorry, but the previous answer was opposite. But despite of that, I do not like additional packages. I've started to use jails more often not only from a security issue, but also cause of the problems with upgrade. The more packages you have in the system - the harder to upgrade them if the last upgrade was not done recently. But this is the other story. 3. Why is it a problem if the port/package you need to install in the early stages has dependencies? The amount of time you need to get and compile all the stuff. The first packages I usually install is the 'bash' and 'portupgrade'. I didn't ever count dependences for just two packages I need, but it is about 15-20 of them. I can do working system solving the most of needed task without both of them. And I do my job while they are installing (or better to say their dependences). If I need to fix some detached from the internet systems, I do not need to keep the set of packages for set of branches and for set of dependences just only sources, base system, my hands and my head. rik Thanks, Doug ___ 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
Re: CVS removal from the base
Jase Thew wrote: On 03/12/2011 14:48, Roman Kurakin wrote: Jase Thew wrote: On 03/12/2011 09:21, Roman Kurakin wrote: [SNIP] You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. As has been pointed out elsewhere in this thread, CVS doesn't cover csup, a utility in base which allows you to obtain the source trivially for the scenario you provide above. (Explicity ignoring cvsup which requires a port). Does csup allows to checkout a random version from local cvs mirror? So better to say csup(cvsup) does not cover cvs. Not quite sure what you are referring to by random version. But csup certainly allows you to obtain the source as described in your scenario above (last available source, even source at a particular point in time). By random version I mean any exact version I need, not only head of branch or tag. rik Also, when I said CVS doesn't cover csup, I meant any removal of CVS from base would still leave csup available for obtaining source. Regards, Jase. ___ 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 ___ 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
Re: CVS removal from the base
On 12/04/11 01:25, Doug Barton wrote: [snip] Replying to a somewhat random mail in this thread. Has anyone considerede that the people actually using CVS for getting the source might be somewhat overrepresented on freebsd-current? If I had to guess, the average user is using either freebsd-update or csup (or even cvsup) to update a freshly installed system. Those that need the added flexibility provided by using CVS directly should be fully able to install it using pkg_add. Personally I pkg_add screen on new systems before doing anything else. I have never considered that a problem. I use CVS myself from time to time, but I see no need for it to be in base for that reason. BTW. I think the bikeshed should be painted blue. -- Christian Laursen ___ 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
Re: CVS removal from the base
I understand that this is not my business at all :) But anyway, IMHO, you should take GPL-free effort as an example. When you visit http://wiki.freebsd.org/GPLinBase you easily can see what going to be dumped, why, and with what it's going to be replaced. What I mean exactly - throw emails to mail list like this, telling that we need to specify software list for removal, provide page in wiki, with each software listed, propose something in exchange, collect not opinions, but real usage examples, and some stats, like feature A is used by approx 100 peoples. Or Feature B is used by 3 peoples, but there's no replace ATM. If you think it's time to move from CVS, create page in wiki, find most frequent use cases, think about replacing them with other tools, collaborate with peoples, create simple pro/con table with free editing. I'm sure that very few peoples, or even no one know _every_ usage of FreeBSD base, so deep investigating on each item is would be necessary. That's only my 2c. -- Regards, Alexander Yerenkow ___ 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
Re: CVS removal from the base
Christian Laursen wrote: On 12/04/11 01:25, Doug Barton wrote: [snip] Replying to a somewhat random mail in this thread. Has anyone considerede that the people actually using CVS for getting the source might be somewhat overrepresented on freebsd-current? Probably you are right. I guess I would never use CVS if I wouldn't be a software developer and was not able to fix smth by my self. But as a developer I like to see the tool I got accustomed out of the box as it was to for many years. Especially after I've started to help to friends working in companies with restricted Internet access or detached systems. I've started to hate most of linux distributions since they do not have almost any tool for digging and solving problems. But with FreeBSD I even can solve the problem from my seat just giving instructions by phone or skype. rik If I had to guess, the average user is using either freebsd-update or csup (or even cvsup) to update a freshly installed system. Those that need the added flexibility provided by using CVS directly should be fully able to install it using pkg_add. Personally I pkg_add screen on new systems before doing anything else. I have never considered that a problem. I use CVS myself from time to time, but I see no need for it to be in base for that reason. BTW. I think the bikeshed should be painted blue. ___ 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
Re: CVS removal from the base
Christian Laursen wrote: [...] I use CVS myself from time to time, but I see no need for it to be in base for that reason. By the way, since there is no way to count +/- I guess the rule do not brake that is working or provide a way to do the same should work. If there is a number of users of smth it should not be broken. csup/cvsup does not provide the same. rik BTW. I think the bikeshed should be painted blue. ___ 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
Re: CVS removal from the base
On Sun, Dec 4, 2011 at 7:01 PM, Roman Kurakin r...@inse.ru wrote: Christian Laursen wrote: [...] I use CVS myself from time to time, but I see no need for it to be in base for that reason. By the way, since there is no way to count +/- I guess the rule do not brake that is working or provide a way to do the same should work. If there is a number of users of smth it should not be broken. csup/cvsup does not provide the same. Actually, a whole lot of stuff that was still perfectly useable has been deprecated over the years. I'm thinking of net/freebsd-uucp for example. Instead of moving all this functionality into ports, and therefore into a rather unstable moving target (how sure are we that the corresponding distfiles will stay available as long as /usr/src?), I'd have preferred that it be moved into a dedicated part of the base tree, e.g. /usr/old (or /usr/deprecated, or /usr/historic, /usr/vintage, whatever). Therefore, we could simply add /usr/old/bin to PATH, and link against /usr/old/lib, use headers from /usr/old/include, have the source in /usr/old/src, and so on. If you don't want to build the system with that, just add a knob in /usr/src.conf to exclude /usr/old. That's the kind of stable system I'd wish for FreeBSD instead of the current model or slowly eroding functionality and mysteriously disappearing utilities _and_ source code. rik -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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
Re: CVS removal from the base
On Sat, 3 Dec 2011, Doug Barton wrote: On 12/3/2011 5:03 AM, sth...@nethelp.no wrote: The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. I don't think of myself as change-averse. I've been using FreeBSD since 1996, and there have been lots of changes since that time. But two of the most important reasons I still use FreeBSD are: - Stability: Both in the sense of stays up basically forever, and in the sense of changes to interfaces and commands are carefully thought through and not applied indiscriminately. For instance, I like very much the fact that the ifconfig command can configure VLANs etc - while Linux has introduced new commands to do this. Agreed. - The base system is a *system* and comes with most of what I need, for instance tcpdump and BIND. For me the fact that I don't need to install lots of packages to have a usable system is a *good* thing. So 2 things here that I really wish people would think about. 1. If you're using *any* ports/packages then you're already participating in the larger operating *system* that I described, so installing a few more won't hurt. (Seriously, it won't.) 2. In (the very few) areas where integration of 3rd party apps into the base makes sense, no problem. But at this point the fact that a lot of 3rd party stuff is changing more rapidly than it used to, and often in incompatible ways and/or at incompatible schedules with our release process, means that we have to re-think how we do this. You mentioned BIND, which is a great example of 2. above. I'll have more to say about this soon, but my plan is to remove it from the base for 10.x because the current situation is unmanageable. In my mind, your 2. above is an example to keep BIND in the base. When I build FreeBSD from sources, I know that everything in src/ works together. I can update my system and be reasonably assured of that. However, updating ports is not at all like that. There is much more work involved in updating ports - you really need an extra test box to make sure that everything works together before updating the deployed system. One might argue that you need an extra test box even for updating src/ only, but in my experience it's not been nearly as necessary as updating ports. We don't have @ports resources for it, but in a perfect world there would be a ports branch for each supported FreeBSD branch. I would like security updates and bug fixes for ports, but not latest and greatest stuff. I like BIND in base (I won't argue against removing it, just stating my preference), and I would also like to see LDAP (at least client) in base. IMHO, FreeBSD base should include everything necessary to work in a networked environment. -- 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
Re: CVS removal from the base
On 12/3/11 6:40 PM, Adrian Chadd wrote: The problem I have with all of this is pretty simple. With the CVS in base, it's treated like the (mostly) rest of the system in a stable release - ie, people don't simply keep updating it to the latest and greatest without some testing. If there are any critical bugs or security flaws, they're backported. The port isn't upgraded unless it has to be, and then if it's a major update, there are plenty of eyeballs to review it. It's in /src, after all. But with ports, the ports tree only has the latest version or two; sometimes a few major versions to choose from (eg apache), but we don't maintain the same kind of package versions that Linux operating system packages do. So it's entirely possible the CVS port maintainer updates the port to the latest and greatest, which works for him - and it breaks someone's older CVS repository somehow. I'd be happier with the idea of things moving into ports if the ports tree did have stable snapshots which had incremental patches for bug/security fixes, rather than upgrade to whatever the port maintainer chooses. I'm all for change, but it seems those pushing forward change seem to be far exceeding the comfortable level of more conservative people; or those with real needs. Those who have relied on FreeBSD's stable release source tree being that - stable - whilst ports moves along with the latest and greatest as needed. It doesn't matter that you may do a fantastic job with a stable CVS port - what matters is how people perceive what you're doing. It just takes one perceived screwup here for the view to shift that freebsd is going the way of linux. And then we lose a whole lot of what public good opinion FreeBSD has. ;-) I propose we create a companion directory to src in SVN and cal it sysports it uses the ports infrastructure in organization (though may be more hierarchical) but is populated with items that have come out of the 'src' tree. it is shipped along with src and revisioned WITH src. basically a privileged set of primary packages. both ports and src maintainers have access to them and they are tested as part of the release engineering process. 2c, Adrian ___ 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 ___ 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
Re: CVS removal from the base
On 12/4/2011 12:19 PM, Julian Elischer wrote: I propose we create a companion directory to src in SVN and cal it sysports it uses the ports infrastructure in organization (though may be more hierarchical) but is populated with items that have come out of the 'src' tree. it is shipped along with src and revisioned WITH src. basically a privileged set of primary packages. both ports and src maintainers have access to them and they are tested as part of the release engineering process. Julian, You've proposed this before, and the more I've thought about it the more I like it. :) In fact, the other day a bunch of us in #bsdports were kicking it around and the idea was generally well received. (I think we slightly preferred the category system, but that's an implementation detail.) My (personal) plan is to start pushing for this after the 9.0-RELEASE, and after the ports repo svn conversion. That's one of the reasons that I want to start socializing the idea now. In regards to having this new category be supported as part of the release process, we've already received tentative support from the release engineering team for the idea of having a small number of critical packages on the install medium and offered to the user as options at install time. So the seeds have been planted for this idea, and I'm hoping to see it grow in the coming months. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: CVS removal from the base
On Sun, Dec 4, 2011 at 1:22 PM, Doug Barton do...@freebsd.org wrote: On 12/4/2011 12:19 PM, Julian Elischer wrote: I propose we create a companion directory to src in SVN and cal it sysports it uses the ports infrastructure in organization (though may be more hierarchical) but is populated with items that have come out of the 'src' tree. it is shipped along with src and revisioned WITH src. basically a privileged set of primary packages. both ports and src maintainers have access to them and they are tested as part of the release engineering process. Julian, You've proposed this before, and the more I've thought about it the more I like it. :) In fact, the other day a bunch of us in #bsdports were kicking it around and the idea was generally well received. (I think we slightly preferred the category system, but that's an implementation detail.) My (personal) plan is to start pushing for this after the 9.0-RELEASE, and after the ports repo svn conversion. That's one of the reasons that I want to start socializing the idea now. In regards to having this new category be supported as part of the release process, we've already received tentative support from the release engineering team for the idea of having a small number of critical packages on the install medium and offered to the user as options at install time. So the seeds have been planted for this idea, and I'm hoping to see it grow in the coming months. Doug 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 to what to name the new area, I vote for burnt orange with blue trim. Go Broncos! (American football for those out of the Estados Unidos.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
Re: CVS removal from the base
On 4. Dec 2011, at 18:07 , C. P. Ghost wrote: On Sun, Dec 4, 2011 at 7:01 PM, Roman Kurakin r...@inse.ru wrote: Christian Laursen wrote: [...] I use CVS myself from time to time, but I see no need for it to be in base for that reason. By the way, since there is no way to count +/- I guess the rule do not brake that is working or provide a way to do the same should work. If there is a number of users of smth it should not be broken. csup/cvsup does not provide the same. Actually, a whole lot of stuff that was still perfectly useable has been deprecated over the years. I'm thinking of net/freebsd-uucp for example. Which is a good example as - to my memory - it needs cvs to build. Moving our CVS (and yes the base CVS has quite some modifications still I think) into ports would probably mean taking the CVS history and run into a chicken and egg problem;-) We'll need our CVS probably for another 2-3 years I think as some non-significant infrastructure will still depend on it even after docs and ports moved away from it. Some others have suggested things like lpd however which could probably go to ports as well as it's anther conflict these days for most people using cups or similar anyway. I can think of more but we shouldn't be overly eager either or we'll end up with a README in src/ saying please install the following ports;-) /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!___ 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
Re: CVS removal from the base
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.
randy
___
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
Re: CVS removal from the base
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.
Some of them would come from the current system sources and some of
them would be
what are currently 'normal' ports but we consider them to be 'basic'
and 'extra supported'
Examples of the first type would be bind, sendmail, cvs, and examples
of the second type would be perl, bash, maybe python, and possibly a
very minimal set of the
X11 packages.
These are things we talk about having extra support for in the
installer anyhow.
I also suggest that said packages include a plugin for
sysinstall/bsdinstall. so that it can ask its own
quesitons during install.
randy
___
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
___
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
Re: CVS removal from the base
Am 05.12.2011 um 00:36 schrieb Randy Bush: 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 [] 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. Most of that stuff should be solved by a configuration-management system - or (partly) by an automated installation. BTW: Does anybody have a link to some documentation how that (PXE-install etc.) is supposed to be done in 9.0? Personally, I don't think cvs should be removed any time soon: - it's AFAIK stable, doesn't change a lot - doesn't introduce vulnerabilities every other month - will be needed for some time for historic reasons BIND OTOH is something different. But even on the couple of servers we actually use BIND, we like to have a version that is supported over the lifetime of the FreeBSD system it's installed on. As has been said, FreeBSD (as of 8.2 - haven't had the chance to look into 9.0 a lot) is a nice system with a lot of functionality without installing lot's of packages. Just FYI: we use rubygem-chef for configuration-management, but we don't think it would be a good idea to have ruby in the base-system, even though we need it on every system anyway... ___ 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
Re: CVS removal from the base
BIND OTOH is something different. what's bind? :) randy ___ 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
Re: CVS removal from the base
On Sun, 04 Dec 2011 16:42:04 PST Julian Elischer jul...@freebsd.org wrote:
On 12/4/11 3:36 PM, Randy Bush wrote:
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.
Some of them would come from the current system sources and some of
them would be
what are currently 'normal' ports but we consider them to be 'basic'
and 'extra supported'
Examples of the first type would be bind, sendmail, cvs, and examples
of the second type would be perl, bash, maybe python, and possibly a
very minimal set of the
X11 packages.
These are things we talk about having extra support for in the
installer anyhow.
I also suggest that said packages include a plugin for
sysinstall/bsdinstall. so that it can ask its own
quesitons during install.
A while back I had toyed with a config based approach. The
idea is you install a minimal system and then use one of the
predefined system configs to bring the system upto a desired
state. The same config will use your local script of the same
name if one exists, to allow for local modifications. The
same config (or an updated version) can be rerun after an
update.
Basically the idea is that you are dealing with a system as a
_whole_ for the purpose of install/update/convert/replicate.
You are capturing the personality or metadata of a system
a single file (it in turn relies on a small set of small text
files). This can be used for other purposes as well.
A config is essentially names of packages to install, variable
names, names of any pre/post external scripts to run, and
other included configs. But no executable logic here!
If this is used, a new release would also contain a repo for
every predefined script -- this makes it easy to see what
changed and deal with it.
Benefits:
- people can consistently customize their setup and keep
it so after an upgrade
- what is included in the base system becomes largely
irrelevant
- you can check/fix system personality at any time
- you can generate a local config easily
- can exactly replicate the same config on multiple machines
- can systematically change the personality of your system
- you can integrate this in sysinstall (and provide more
flexibility)
- you can define your own specialized configs for whatever
purpose.
To give you an idea:
syscfg install foo# install foo on a new installation
syscfg set foo# change existing (unconfigured) system to foo
syscfg convert bar# change existing (configured) system to bar
syscfg diff foo # compare local system against foo
syscfg [-f] check # check and optionally fix
syscfg update
You would need to tell it where to get its data (either a
released ISO or a site). Lot of details would have to be
worked out.
Unfortunately I don't get to use FreeBSD much these days @
work and my home setup doesn't change much.
___
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
Re: CVS removal from the base
Le 05/12/2011 03:00, Randy Bush a écrit : BIND OTOH is something different. what's bind? :) http://www.isc.org/software/bind Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net ___ 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
Re: CVS removal from the base
BIND OTOH is something different. what's bind? :) http://www.isc.org/software/bind see the smily? bind is not in my install set. if i need an on-system cache, i use unbound. randy ___ 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
Re: CVS removal from the base
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?
--
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
Re: CVS removal from the base
Doug Barton wrote: [...] The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. rik Doug ___ 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
Re: CVS removal from the base
The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. I don't think of myself as change-averse. I've been using FreeBSD since 1996, and there have been lots of changes since that time. But two of the most important reasons I still use FreeBSD are: - Stability: Both in the sense of stays up basically forever, and in the sense of changes to interfaces and commands are carefully thought through and not applied indiscriminately. For instance, I like very much the fact that the ifconfig command can configure VLANs etc - while Linux has introduced new commands to do this. - The base system is a *system* and comes with most of what I need, for instance tcpdump and BIND. For me the fact that I don't need to install lots of packages to have a usable system is a *good* thing. You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. I use CVS (or rather csup) to keep the base system up to date. I would be perfectly okay with using a different utility - however, I would strongly prefer that this utility was included in the base system. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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
Re: CVS removal from the base
Jase Thew wrote: On 03/12/2011 09:21, Roman Kurakin wrote: Doug Barton wrote: [...] The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. As has been pointed out elsewhere in this thread, CVS doesn't cover csup, a utility in base which allows you to obtain the source trivially for the scenario you provide above. (Explicity ignoring cvsup which requires a port). Does csup allows to checkout a random version from local cvs mirror? So better to say csup(cvsup) does not cover cvs. rik Regards, Jase. ___ 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
Re: CVS removal from the base
Rik, On Sat, Dec 3, 2011 at 4:21 PM, Roman Kurakin r...@inse.ru wrote: The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. Do you really use CVS and not cvsup/csup? CVS != csup. Max ___ 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
Re: CVS removal from the base
Hello! On Sat, Dec 3, 2011 at 8:03 PM, sth...@nethelp.no wrote: I use CVS (or rather csup) to keep the base system up to date. I would be perfectly okay with using a different utility - however, I would strongly prefer that this utility was included in the base system. CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. Max ___ 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
Re: CVS removal from the base
Max Khon f...@samodelkin.net wrote: As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Those who still use it for development can install ports/devel/opencvs Rather ports/devel/cvs-devel. Maybe we still need a regular cvs port. -- Christian naddy Weisgerber na...@mips.inka.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
Re: CVS removal from the base
On 12/2/11 4:27 AM, Max Khon wrote: In my opinion it is just another piece of bitrot that resides in the base system for no real reasons. I agree, especially since all the development work is being done on SVN and then is exported back to CVS, if I am not mistaken[1]. We've done the hard part, moving the majority of development over to SVN. [1]: http://people.freebsd.org/~peter/svn_notes.txt -- Sean M. Collins ___ 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
Re: CVS removal from the base
On Sat, 3 Dec 2011, Max Khon wrote: Hello! On Sat, Dec 3, 2011 at 8:03 PM, sth...@nethelp.no wrote: I use CVS (or rather csup) to keep the base system up to date. I would be perfectly okay with using a different utility - however, I would strongly prefer that this utility was included in the base system. CVS != csup. I wonder how many people will express their sentiments about CVS when they really mean cvsup/csup. We also use CVS (not cvsup/csup) after installing a fresh system. We mirror the CVS repo on an internal machine, then use CVS to checkout the latest HEAD or -stable from the internal mirror. The checkout from the internal mirror is much faster than trying to do it over our internet link (and that doesn't always work - we may not even be connected to the internet at times). Note that no ports are needed to update a system in this scenario. Also note that I can checkout any branch or from any known good date where the system builds and works. I would love to mirror the SVN repo in the same way and have an 'svn' in base, or at least something that could replace CVS in the above scenario. -- 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
Re: CVS removal from the base
On Fri, Dec 2, 2011 at 10:27 AM, Max Khon f...@samodelkin.net wrote: Hello! I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Those who still use it for development can install ports/devel/opencvs (like all the src/ developers do for ports/devel/subversion/). In my opinion it is just another piece of bitrot that resides in the base system for no real reasons. This bitrot is being used daily here. And very heavily at that, thank you very much. Not every CVS repo is easily converted into newfangled SVN, GIT, Mercurial etc.. repos; thus moving away from CVS in real life is sometimes pretty painful, if not utterly impossible (without heavy hacking and tweaking). I realize how much better and easier to use those new SCMs are, but CVS still has its uses. Please refrain from killing functionality that is often needed out-of-the-box on machines with no ports installed. I understand the desire to move as much as possible from our userland to ports and to end up with a minimal system, but isn't this getting a bit too eager? Max Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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
Re: CVS removal from the base
Max Khon wrote: Rik, On Sat, Dec 3, 2011 at 4:21 PM, Roman Kurakin r...@inse.ru wrote: The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. Do you really use CVS and not cvsup/csup? CVS != csup. I use ctm/csup to get(update) CVS source tree and cvs to checkout the exact version I need. Having cvs tree locally it is more convenient to keep one central repo for updating local systems based on different branches and to roll back a little bit for example with the ports tree in case I can't upgrade all needed ports to current for some reasons and got some problems with dependences. I can have what ever development system on the development machine, but unlikely I'll have one on all production systems by default since of additional potentially buggy packages, additional dependences, additional upgrade problems etc. rik Max ___ 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 ___ 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
Re: CVS removal from the base
On Sat, Dec 3, 2011 at 1:21 AM, Roman Kurakin r...@inse.ru wrote: Doug Barton wrote: [...] The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependencies. I have to agree with Roman. It's simply far too early to think of removing cvs from the base OS. If we can come up with a way to replace the functionality of csup with svn under it, that would be great, but it may be a long time coming. Until it does, cvs needs to remain with all of the awkwardness of maintaining cvs when the actual source of truth is in svn. The time will hopefully come, but I don't see it in the 10.0 time frame. OTOH, I can see Doug's argument. I'm sure that, even when no real need exists for CVS in the base, I imagine there will be loud objections to its removal, though I suspect Doug's comments were largely spawned by the debate on the default setting for building profile libraries. (And, IMHO, Doug is right on that one.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
Re: CVS removal from the base
Hi Daniel; --- On Sat, 12/3/11, Daniel Eischen deisc...@freebsd.org wrote: ... I would love to mirror the SVN repo in the same way and have an 'svn' in base, or at least something that could replace CVS in the above scenario. I have to say I am surprised by all the people that still use CVS (for their own good reasons). It still would be helpful if cvs users could evaluate OpenCVS: it's been experimental for ages now. It does seem to have some advantage (other than the license) in that it's smaller and better maintained (or at least not too dead). cheers, Pedro. ___ 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
Re: CVS removal from the base
On 12/03/2011 17:29, Sean M. Collins wrote: [...] all the development work is being done on SVN and then is exported back to CVS, if I am not mistaken[1]. [...] Aren't ports still updated with CVS? Cheers Michiel ___ 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
Re: CVS removal from the base
On Sat, Dec 3, 2011 at 12:03 PM, Michiel Boland mich...@boland.org wrote: On 12/03/2011 17:29, Sean M. Collins wrote: [...] all the development work is being done on SVN and then is exported back to CVS, if I am not mistaken[1]. [...] Aren't ports still updated with CVS? Just to back up that point: until CVS is completely unused by releng (docs, ports are still done via CVS), it really shouldn't be removed from base (no matter how broken or undeveloped it is). WITHOUT_CVS (assuming that the knob actually works as advertised unlike many of our other knobs -- which last time I checked did in fact work) in /etc/src.conf suffices for now. Thanks, -Garrett off-topic I used to work with a group that used CVS extensively for managing changes to FreeBSD. It made my life a lot easier when we need to evaluate changes to code with FreeBSD to ensure we were license compliant.. it was very difficult to have to wade through with Protex Blackduck because it tosses up a ton of false positives, so any way we could avoid doing that by using an SCM that produces sane output which cv?sup doesn't currently do, all for the better. /off-topic ___ 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
Re: CVS removal from the base
On 12/3/2011 5:03 AM, sth...@nethelp.no wrote: The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. I don't think of myself as change-averse. I've been using FreeBSD since 1996, and there have been lots of changes since that time. But two of the most important reasons I still use FreeBSD are: - Stability: Both in the sense of stays up basically forever, and in the sense of changes to interfaces and commands are carefully thought through and not applied indiscriminately. For instance, I like very much the fact that the ifconfig command can configure VLANs etc - while Linux has introduced new commands to do this. Agreed. - The base system is a *system* and comes with most of what I need, for instance tcpdump and BIND. For me the fact that I don't need to install lots of packages to have a usable system is a *good* thing. So 2 things here that I really wish people would think about. 1. If you're using *any* ports/packages then you're already participating in the larger operating *system* that I described, so installing a few more won't hurt. (Seriously, it won't.) 2. In (the very few) areas where integration of 3rd party apps into the base makes sense, no problem. But at this point the fact that a lot of 3rd party stuff is changing more rapidly than it used to, and often in incompatible ways and/or at incompatible schedules with our release process, means that we have to re-think how we do this. You mentioned BIND, which is a great example of 2. above. I'll have more to say about this soon, but my plan is to remove it from the base for 10.x because the current situation is unmanageable. The FOSS world has changed a lot in the last 20 years, and decisions that were made in the early days, while appropriate at the time, need to be reexamined. I use CVS (or rather csup) to keep the base system up to date. The point has been made before, but you do realize that cvs and csup are 2 completely different things, and that noone is recommending removal of csup from the base, right? Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: CVS removal from the base
On 12/3/2011 1:21 AM, Roman Kurakin wrote: Doug Barton wrote: [...] The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. You are right in general, except one small factor. We are talking about bootstrap. You realize that you just 100% demonstrated the truth of what I wrote above, right? :) CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. I want to ask some serious questions here, because I genuinely want to understand your thought process. 1. Do you install *any* ports/packages on a new system before you update the source? 2. If so, why is installing one more unthinkable? 3. Why is it a problem if the port/package you need to install in the early stages has dependencies? Thanks, Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: CVS removal from the base
The problem I have with all of this is pretty simple. With the CVS in base, it's treated like the (mostly) rest of the system in a stable release - ie, people don't simply keep updating it to the latest and greatest without some testing. If there are any critical bugs or security flaws, they're backported. The port isn't upgraded unless it has to be, and then if it's a major update, there are plenty of eyeballs to review it. It's in /src, after all. But with ports, the ports tree only has the latest version or two; sometimes a few major versions to choose from (eg apache), but we don't maintain the same kind of package versions that Linux operating system packages do. So it's entirely possible the CVS port maintainer updates the port to the latest and greatest, which works for him - and it breaks someone's older CVS repository somehow. I'd be happier with the idea of things moving into ports if the ports tree did have stable snapshots which had incremental patches for bug/security fixes, rather than upgrade to whatever the port maintainer chooses. I'm all for change, but it seems those pushing forward change seem to be far exceeding the comfortable level of more conservative people; or those with real needs. Those who have relied on FreeBSD's stable release source tree being that - stable - whilst ports moves along with the latest and greatest as needed. It doesn't matter that you may do a fantastic job with a stable CVS port - what matters is how people perceive what you're doing. It just takes one perceived screwup here for the view to shift that freebsd is going the way of linux. And then we lose a whole lot of what public good opinion FreeBSD has. ;-) 2c, Adrian ___ 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
Re: CVS removal from the base
On Sat, Dec 3, 2011 at 9:40 PM, Adrian Chadd adr...@freebsd.org wrote: The problem I have with all of this is pretty simple. With the CVS in base, it's treated like the (mostly) rest of the system in a stable release - ie, people don't simply keep updating it to the latest and greatest without some testing. If there are any critical bugs or security flaws, they're backported. The port isn't upgraded unless it has to be, and then if it's a major update, there are plenty of eyeballs to review it. It's in /src, after all. But with ports, the ports tree only has the latest version or two; sometimes a few major versions to choose from (eg apache), but we don't maintain the same kind of package versions that Linux operating system packages do. So it's entirely possible the CVS port maintainer updates the port to the latest and greatest, which works for him - and it breaks someone's older CVS repository somehow. I'd be happier with the idea of things moving into ports if the ports tree did have stable snapshots which had incremental patches for bug/security fixes, rather than upgrade to whatever the port maintainer chooses. I'm all for change, but it seems those pushing forward change seem to be far exceeding the comfortable level of more conservative people; or those with real needs. Those who have relied on FreeBSD's stable release source tree being that - stable - whilst ports moves along with the latest and greatest as needed. It doesn't matter that you may do a fantastic job with a stable CVS port - what matters is how people perceive what you're doing. It just takes one perceived screwup here for the view to shift that freebsd is going the way of linux. And then we lose a whole lot of what public good opinion FreeBSD has. ;-) 2c, Adrian Over the years , by installing and studying many operating system distributions , my opinions for FreeBSD has been converged toward the following : Supplying only a console-mode FreeBSD as a release is making FreeBSD unusable for peoples who they are not computing experts . To allow less experienced people to use FreeBSD easily , it is necessary to include a selected ports/packages into release distributions , therefore into so-called BASE as a /ports or /packages part . When a new FreeBSD release will be installed , it is becoming necessary to install many packages additionally , and setting many parameters in the *.conf , etc. , files to make it usable . One unfortunate situation is that some packages are NOT working at the release moment . In the packages tree , it seems that there is no any regular update policy for a specific release . It is possible to make port_name , but this is NOT so much usable also : For a specific package , which is installing within less than 30 minutes by pkg_add , required more than eighteen hours by make ... . Reason was that MAKE is an extremely STUPID system ( without BRAIN ) because , it is NOT able to remember that it has completed making a package part a few seconds before , and it is starting the same steps to apply up to the point that it is not necessary to make it once more ( after applying many steps which was applied before ) . One immediate reaction to such an idea is to mention PC-BSD . If the PC-BSD is the solution , what is the reason of maintaining a large FreeBSD ports tree and consuming a huge amount of efforts to manage a so large repository ? Another possibility is FreeBSD/Debian combination . When compared to Linux/Debian , it is unusable also , because , I do NOT know the reason , it is VERY slow . I am NOT suggesting to include as many packages as possible : Just an OPTIMUM number of packages to allow the users to have a working installation out of the box . It is possible to obtain an idea if there is a statistics set about downloaded packages by pkg_add . After setting a percentage to satisfy user needs , it will be easy to make a list of packages to include . Even myself I am NOT using FreeBSD , because I am NOT able to use it : For example , 9.0 RC2 : There is NO KDE4 at this moment , KDE3 is NOT working , GNOME2 is NOT working , the others I am NOT using because they are not capable as much as KDE or GNOME . If such a selected packages maintained within BASE /ports , or /packages , there will NOT be such difficulties to use the FreeBSD ( difficulty is transferred from the user to FreeBSD teams ) . Thank you very much . Mehmet Erol Sanliturk ___ 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
Re: CVS removal from the base
On 4 December 2011 11:59, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote: Supplying only a console-mode FreeBSD as a release is making FreeBSD unusable for peoples who they are not computing experts . And the PCBSD crowd have stepped up to fill this gap. So we're free to concentrate on doing what we're good at, those who are good at polish and gui stuff can concentrate on what they're good at, and we just communicate well :) Thus, I don't even see this as a problem. I'm even using pcbsd 9, because guis are easy for doing desktop/VM development. ;) Adrian ___ 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
Re: CVS removal from the base
On 03/12/2011 14:48, Roman Kurakin wrote: Jase Thew wrote: On 03/12/2011 09:21, Roman Kurakin wrote: [SNIP] You are right in general, except one small factor. We are talking about bootstrap. CVS is used by many as the one of the ways to get the sources to the freshly installed system to recompile to the last available source. It will become inconvenient to do it through the process of installing some ports for that. Especially if corresponding ports would require some other ports as dependences. As has been pointed out elsewhere in this thread, CVS doesn't cover csup, a utility in base which allows you to obtain the source trivially for the scenario you provide above. (Explicity ignoring cvsup which requires a port). Does csup allows to checkout a random version from local cvs mirror? So better to say csup(cvsup) does not cover cvs. Not quite sure what you are referring to by random version. But csup certainly allows you to obtain the source as described in your scenario above (last available source, even source at a particular point in time). Also, when I said CVS doesn't cover csup, I meant any removal of CVS from base would still leave csup available for obtaining source. Regards, Jase. ___ 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
CVS removal from the base
Hello! I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Those who still use it for development can install ports/devel/opencvs (like all the src/ developers do for ports/devel/subversion/). In my opinion it is just another piece of bitrot that resides in the base system for no real reasons. Max ___ 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
Re: CVS removal from the base
Max Khon wrote: Hello! I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Those who still use it for development can install ports/devel/opencvs (like all the src/ developers do for ports/devel/subversion/). In my opinion it is just another piece of bitrot that resides in the base system for no real reasons. By the way, there is one other use case of cvs. Personally I use cvs instead of cvsup to checkout whatever version I need to compile. It is very useful to have such ability out of the box without any extra ports. rik Max ___ 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 ___ 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
Re: CVS removal from the base
On 2011-Dec-02 16:27:34 +0700, Max Khon f...@samodelkin.net wrote: I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. I'd agree that it's still too early. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. There's more to it than just converting the repo from CVS to SVN - the official distribution and build systems have to be converted as well. The official build system for RELENG_8 remains CVS and (AFAIK) the official repo distribution system remains CVS-based (csup/cvsup) because there's no suitable SVN-based equivalent. IMHO, if those issues can be resolved in the near future then it might be possible to deprecate CVS before 9.1 and remove it in 10 but I suspect removal in 11 is a more realistic timeframe. Those who still use it for development can install ports/devel/opencvs (like all the src/ developers do for ports/devel/subversion/). Agreed. In my opinion it is just another piece of bitrot that resides in the base system for no real reasons. You are, of course, welcome to your opinion. I -- Peter Jeremy pgpFQ8HoLQMz7.pgp Description: PGP signature
Re: CVS removal from the base
Peter, On Fri, Dec 2, 2011 at 6:54 PM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Dec-02 16:27:34 +0700, Max Khon f...@samodelkin.net wrote: I know that it is too early to speak about this, but I would like the dust in the mailing lists to settle down before real actions can be taken. I'd agree that it's still too early. As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. There's more to it than just converting the repo from CVS to SVN - the official distribution and build systems have to be converted as well. I presumed that make release will use svn for doing ports/doc checkouts after repos are converted. The official build system for RELENG_8 remains CVS and (AFAIK) the official repo distribution system remains CVS-based (csup/cvsup) because there's no suitable SVN-based equivalent. I am not suggesting to change anything in RELENG_9 or even RELENG_8. And csup/cvsup != cvs. IMHO, if those issues can be resolved in the near future then it might be possible to deprecate CVS before 9.1 and remove it in 10 but I suspect removal in 11 is a more realistic timeframe. Max ___ 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
Re: CVS removal from the base
I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. Adrian ___ 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
Re: CVS removal from the base
On Fri, Dec 02, 2011 at 04:27:34PM +0700, Max Khon wrote: Hello! ... As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Well. We _could_ replace it with SCCS. -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? ___ 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
Re: CVS removal from the base
On Fri, Dec 2, 2011 at 8:36 AM, Diane Bruce d...@db.net wrote: On Fri, Dec 02, 2011 at 04:27:34PM +0700, Max Khon wrote: Hello! ... As soon as ports/ (and doc/) are moved to SVN I do not see any compelling reasons for keeping CVS in the base system. Well. We _could_ replace it with SCCS. -- - d...@freebsd.org d...@db.net http://www.db.net/~db Why leave money to our children if we don't leave them the Earth? http://en.wikipedia.org/wiki/Source_Code_Control_System Thank you very much . Mehmet Erol Sanliturk ___ 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
Re: CVS removal from the base
On 12/02/2011 04:35, Adrian Chadd wrote: I think you're missing the point a little. The point is, you have to keep in mind how comfortable people feel about things, and progress sometimes makes people uncomfortable. I think you should leave these changes bake for a while and let people get comfortable with the changing status quo. The fact that we have so many people who are radically change-averse, no matter how rational the change; is a bug, not a feature. This particular bug is complicated dramatically by the fact that the majority view seems to lean heavily towards If I use it, it must be the default and/or in the base rather than seeing ports as part of the overall operating SYSTEM. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
