Subject: Fwd: Re: keeping pkgsrc up-to-date
To: None <tech-pkg@netbsd.org>
From: Marton Fabo <morton@eik.bme.hu>
List: tech-pkg
Date: 07/02/2002 20:55:59
This was meant to be sent to tech-pkg in the afternoon, just went to the 
wrong place. Sorry.

>From: Marton Fabo <morton@eik.bme.hu>
>Subject: Re: keeping pkgsrc up-to-date
>Date: Tue, 02 Jul 2002 12:17:04 +0200
>
>
>Well, it looks like I'm not alone with the problem. There are scripts by 
>other people for extracting diff info from pkgsrc-changes mails. The 
>solution doesn't seem to be quite reliable, e.g. because of the 
>email-to-cvs delay.
>
>So, what now. Is a full one day diff of pkgsrc too big for emails 
>distributed in a mailing list? Isn't it absolutely possible to have such a 
>list?
>
>I'm not really familiar with how cvs works, but as I can understand, 
>changes can be requested since a given date or tag. So why isn't it 
>possible for pkgsrc to remember the unambiquitous tag of the state of 
>pkgsrc on the local machine (the identifier of the state at the last 
>update), and request any changes since then, through cvs or any other 
>mechanism?
>
>As I can understand, sup does something similar, but is quite slow and 
>unreliable. And, the downloadable tarballs should conatin their respective 
>tag, so that after initially fetching it, the next time it is updated no 
>there would be no need to fetch the whole thing again (as it is the case 
>currently with sup).
>
>Somehow, I don't really like cvs' brute-force comapre-each-directory 
>approach, especially for such a multi-ten-thusand-files beast such as pkgsrc.
>
>Well, the slogan on the site is "Solutions and not hacks". What about 
>_solving_ this issue instead of having various hacks?
>
>bye
>mortee