Date: Fri, 23 Jul 2010 16:56:56 +0800 From: Fbsd8 <fbsd8@a1poweruser.com> To: bf1783@gmail.com Cc: freebsd-questions@FreeBSD.org Subject: Re: ports INDEX file Message-ID: <4C495958.5000106@a1poweruser.com> In-Reply-To: <AANLkTinC%2B4-QhC8MBRRoe4qMpEzubBTcJWF4M3pya866@mail.gmail.com> References: <AANLkTinC%2B4-QhC8MBRRoe4qMpEzubBTcJWF4M3pya866@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
b. f. wrote: >> Benjamin Lee wrote: >>> On 07/22/2010 06:20 PM, Fbsd8 wrote: >>>> I have a pristine install of 8.0. >>>> There is no /usr/ports directory yet. >>>> I am trying to use the "portcheckout" port and the "porteasy" port to >>>> just populate the ports tree with only the ports I use. >>>> >>>> Problem is in both cases the above ports require an existing INDEX file >>>> to process and since I have none they don't work. >>>> >>>> How can I just download the ports INDEX file? >>>> Portsnap is not a solution. > >> I see in the source of porteasy that its fetching >> http://www.freebsd.org/ports/INDEX-8.bz2 >> >> How can I verify this? > > Usually the index file is placed at $INDEXDIR/$INDEXFILE, as defined > in $PORTSDIR/Mk/bsd.port.mk. In your case, by default, that would be > /usr/ports/INDEX-8. > > As Matthew asked, do you really want to do this? By modern standards, > the space required for the ports tree is modest (~550MB uncompressed), > and you can learn a lot about what's available and how things work by > looking through it. Plus you save the time required to implement this > partial ports tree approach. If you really need to save the disk > space, and don't have other special requirements, then considering > using binary packages instead of compiling from source. > > If you do have special requirements -- e.g., you need to build ports > with non-default options or special flags, or you don't trust foreign > binary packages (in that case, though, you should probably be prepared > to do a lot of work auditing the source code as well), and you don't > have at least one machine with the required disk space, then maybe > this approach is worthwhile. However, that seems unlikely. > > If you pursue the partial ports tree approach, you don't need to make > or fetch an INDEX(which, although it may be a useful summary, may be > inappropriate for parsing dependencies for ports built with > non-default options), and you don't need to use either of the ports > that you mentioned: as someone else said, you could just write a > shell script to fetch the necessary infrastructure Makefiles (those in > /usr/ports/Mk and the needed category subdirectories), and the desired > port and it's dependencies, using cvs(1) (but you have to choose a > server that permits anonymous cvs access, and learn cvs), csup(1) > (configured to use a suitable cvsup server using the ports-all > collection and the -i flag, which would permit you to grab only parts > of that collection), or even an http client like fetch(1) (exploiting > the fact that single ports can be downloaded in tarball form from > cvsweb.freebsd.org in links of the form: > > http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/$CATEGORY/$PORT/$PORT.tar.gz?tarball=1 > > and single Makefiles via other links). > Well first thanks for the info you provided though it was all negative. I will explain what my goal is. First though, I have verified that the /usr/ports/INDEX-8 file can be gotten without the using cvs or cvsup. fetch -m "http://www.freebsd.org/ports/INDEX-8.bz2" does if fact work and the data on the file is as of 3 hours ago. So that indicates its being kept current. The -m means that if the date of the remote file is NOT newer then the local one, the download is bypassed. Now about my project. Since about 4.0 I stopped using the ports tree method. I now all most totally use the package system. I do not upgrade a RELEASE but instead use the "install from scratch" method about a few weeks after a new RELEASE is published. So since the package system is also re-build a new for each new RELEASE, I am all ways in sync. Now there are exceptions to using packages. In my case php5 was changed 3 RELEASES ago to no longer contain the apache module, so I now have to compile php5 from the port. But to short cut the compile process, I pre-install all of php5's dependents as packages. And of course I had to figure out who they all were by hand the first time and built a script that automates the whole procedure. I use cvsup at NEW RELEASE time to populate the empty ports tree with ports-base. Then I use cvsup to checkout the php5 make files and them "make install" and everything comes together just fine. Now the Freebsd method of the 22,000 individual ports each with 3 to 5 files is a method which has out lived its usefulness. TAKE NOTE: NO FLAME WAR INTENDED. I just think a option should exist for us who don't follow the bleeding edge. Sure to some people that big ports tree is no big deal, but I bet they don't do backups. That ports tree directory is a large resource hog if you lift the blinders and look at the big picture. I don't need a reason to convince the budget handlers for money to buy bigger and faster cpu machines or larger disk farms. I come from a world where one has to make do with what one has at hand. So in that light. Anything that can be done to reduce the size of the ports tree is money saved and resources conserved. And I bet I am not alone in the Freebsd world who believes in this. So since I have a method all ready working as I explained above, I am collecting information on the elements needed to write a shell script port application based on the method already described. Figure I will use cvsup to populate the port-base and checkout just the "parent" port make files. Read the INDEX file to automate finding the parent port dependents and reading the /var/db/pkg to skip an dependents all ready installed and then launch pkg_add to install the dependents and on any package failures cycle back and use cvsup to also checkout its make files, before issuing the "make install" on the parent. I an not re-inventing the ports tree, just changing the order in which all ready existing functions are performed. Some times when the horse will not come to the water to drink, you have to take the water to the horse to show him it wont hurt him. So if it takes writing a port application to demonstrate the value of this method to nudge the ports core team to consider alternatives to their method, then so be it. Along this same line of thought, Another area I have problems with is why don't the port make system go and checkout any dependent ports missing make files instead of halting like it does now. When installing a package it will auto install all of it dependents. The make port system should be changed so if a dependents make port files are absent, it pauses and auto checkouts then so the make compile process may continue with out interruption. This would go a very long way toward eliminations the need for a full ports tree. I believe the only reason this has not been done is it goes against the existing method of forcing users to carry a full ports tree. The old shop dies hard. Cant give up its old mind set. Just my 2 cents. WOW, that felt good to get off my chest. hahahahahaha
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C495958.5000106>