ports INDEX file

Fbsd8 fbsd8 at a1poweruser.com
Fri Jul 23 08:57:04 UTC 2010

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

More information about the freebsd-questions mailing list