Date: Mon, 07 Jan 2008 01:01:25 -0500 From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: Michael Lednev <liettneff@bk.ru>, freebsd-questions@freebsd.org, Rudy <crapsh@monkeybrains.net> Subject: Re: [HOW-TO] cvsup for ports -- Re: compact portsnap db Message-ID: <4781C035.4090404@gmail.com> In-Reply-To: <Pine.BSF.3.96.1080107145253.14538A-100000@gaia.nimnet.asn.au> References: <Pine.BSF.3.96.1080107145253.14538A-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Smith wrote: > On Sun, 6 Jan 2008, Aryeh M. Friedman wrote: > >>>>> If you don't have cvsup installed, run this command: # >>>>> pkg_add -r cvsup-without-gui >>>> >>>> It is better to use all ports or all packages so either do: >>> >>> Why do you say that? Do you know of unresolved issues >>> regarding the interactions of port versus package >>> installations? Any references? >> >> I am not currently aware of any conflicts but the fact that they >> have historical been more frequent then inter-port or >> inter-package conflicts leads to the conculsion... unlike either >> of the above they are harder to troubleshoot > > The only problems I've ever seen with installing packages is that > at times the package-building farm gets a bit behind, when you > might need to build a desired newly updated port from source, and > that in some cases a package built with default options may not be > what you want. php5 is one example of the latter, as the default > options do not include mod_php5 which (I gather?) is why most > people install php at all. The main issue is assuming that certain things are installed because that is the way the developers recommend it then you install a package and find out that the maintainer had different ideas. A very good current example is boost vs. boost-python in regards to the requirements for deluge and miro respectivally. An other example is the entire Java tree. > > And yes there are some ports that don't have packages for licencing > etc reasons, though I can't recall ever having to install one of > those. I am the author (but not the maintainer) of such a port (devel/thistest) and there is often very legit reasons for not allowing packages... for example my license requires explicit agreement before you can download the source and/or binaries (because it has specific provisions regarding execution vs. source usage [see my blog for more details... http://www.flosoft-systems.com/flosoft_systems_community/blogs/aryeh/index.php]). > > Not everyone has fast hardware and good bandwidth, so installing > from packages for really big ports - such as X, KDE or Gnome, > j{dk,re}, OO and such - is almost mandatory on smaller systems. > Release CDs install at least the former three as packages of > course, for obvious reasons, and at least around release times, up > to date packages can be expected. My experience has been every time I have attempted to make the two play together well it blows up. It has been so long since I have used a package vs. a port I can't site a specific example. > > I just think saying "it's better to use all ports or all packages" > is poor and maybe misleading advice, particularly expressed without > 'IMHO', as it implies problems that RE should know about - > especially right now! This is more of a long term issue that is being worked on by several groups including the "ports 2.0" team that I am member of [see long set threads in -ports@ regarding ports system re-engineering]... much of the stuff I hint at in this thread is better spelled out there. > >>>> cd /usr/ports/net/cvsup-without-gui make install clean >>>> >>>> or after doing the above do a pkg_delete -a (assuming that >>>> your working with a clean machine [no ports/packages >>>> instaleld except cvsup] >>> >>> Why wouldn't pkg_delete -a remove your just-installed >>> cvsup-without-gui? >> >> Sorry for not being clear I meant before the reinstall (besides >> make install would fail if you hadn't done a pkg_delete -a) > > Hmm ok - thought you might be suggesting that port installs don't > update the package database in /var/db/pkg just the same as pkg_add > does. > >>>>> For more info on the supfile, look at this file on your >>>>> FreeBSD machine: /usr/share/examples/cvsup/ports-supfile >>>>> >>>>> Preferring cvsup to portsnap is kinda like preferring vim >>>>> over emacs... It's a holy war and the vi/cvsup side uses >>>>> less disk space. >>>> >>>> Actually it is not like that at all.. cvsup/csup is the >>>> officially preferred method and any other method is a short >>>> cut of some kind... >>> >>> Please provide a reference URL to 'official' support of this >>> claim? >> >> This is a case of actions by the developer community speaks >> louder then words: >> >> 1. Csup is in the base system thus obvious preferred to either >> cvsup or portsnap > > % which portsnap /usr/sbin/portsnap > >> 2. C(v)sup is more universal 3. The only way to maintain an >> official local repo is via cvsup > > You're talking about updating sources, ports and CVS too. We were > just talking about maintaining the ports tree. I sense nothing > 'official'. To me the "official" method should be the most general... and except for my mistake that portsnap is not in the base system it is no where near as general as c[v]sup.... namely portsnap is a kludge designed for people who are to lazy to learn cvsup > >>>> many of them have very subtle issues that the typical >>>> end-user should not notice but should be aware of... >>> >>> Issues such as? And what other alternatives to c*sup and >>> portsnap exist for ports tree management? >> >> I can think of several off the top my head: >> >> 1. Ftp ports.tar.gz and unpack > > Sure. Plus make fetchindex or such. > >> 2. Maintain a local repo like I do > > Clearly not a job for portsnap :) > >> 3. Use portupgrade in conjunction with the above >> >> I was specifically refeering to the 3rd option when I said there >> where subtle issues. Speicfically the way "make install" >> (recursive) and "portupgrade -a" calculate the build order can >> lead to some issues (like compiling the default OPTIONS before >> asking the user to select OPTIONS) > > It seems that here you're confusing port maintenance and upgrading > tools (portupgrade, portmaster etc and/or make install) with a > choice between c*sup and portsnap for maintaining the ports _tree_ > and INDEX, which is precisely all that portsnap is designed to do, > and does well. Port maintaince == upgrade and downgrade in my book > > Sorry if I sound a bit harsh, but there seems to have been a flurry > of deprecation approaching folklore re installing from packages > recently, and I can't see that it's based on anything much factual. > My last big portupgrade on this 300MHz 5.5-STABLE system began with > 'portupgrade -anPP' which fetched the vast bulk of a hundred or so > ports as packages, saving me many hours - if not days - of > building. YM probably V. > > cheers, Ian > > - -- Aryeh M. Friedman FloSoft Systems, Java Developer Tools http://www.flosoft-systems.com Developer, not business, friendly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHgcA1jRvRjGmHRgQRAuM4AKCymsMI1Z08MSeShQUvd9ACh8UkUQCfYE/t tdax2laluavliOtACO+loqg= =2Zeo -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4781C035.4090404>