Date: Thu, 21 Dec 2000 17:52:27 +0200 From: Peter Pentchev <roam@orbitel.bg> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Andrew Reilly <areilly@bigpond.net.au>, freebsd-ports@FreeBSD.org Subject: Re: Integration of ports and 3rd party anoncvs repositories? Message-ID: <20001221175227.B7974@ringworld.oblivion.bg> In-Reply-To: <3A420FEC.F9A719D9@FreeBSD.org>; from sobomax@FreeBSD.org on Thu, Dec 21, 2000 at 04:13:01PM %2B0200 References: <20001221103408.A76507@gurney.reilly.home> <3A420FEC.F9A719D9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I do not think that creating a new repository was what the original poster has in mind; rather, he meant checking out source from existing repositories for those projects that keep its source there, instead of downloading ready-made tarballs. Many open-source projects do make their source trees availabe through anoncvs, and updating would be a simple matter of running cvs update with a new date tag. Other than that, your xdelta idea makes a lot of sense, especially for those big projects which do *not* make their source available via anoncvs; and I can sympathize about the internet costs :> G'luck, Peter -- If there were no counterfactuals, this sentence would not have been paradoxical. On Thu, Dec 21, 2000 at 04:13:01PM +0200, Maxim Sobolev wrote: > Andrew Reilly wrote: > > > There are some large and fairly rapidly evolving code bases out > > there at the moment. They aren't part of the base FreeBSD > > distribution, but are frequently installed via the ports > > collection: XFree86, Wine, mozilla, kde and gnome, probably > > openoffice soon. All of these are available through incremental > > means: anoncvs, CVSup, or inter-tarball diffs. > > > > Please correct me if I'm wrong here, but the current Ports > > facility is based on the notion of operating from distribution > > tarballs that wind up in /usr/ports/distfiles, one way or > > another. Some of these tarballs are now really big, which (for > > those of us who pay for our bandwidth by the megabyte) is a > > disincentive for staying current. > > > > I've managed to track Wine for a while by building my own > > tarballs incrementally, with the deltas. I'm just about to have > > a go at grabbing XFree86-4.0.2 by CVSup. > > > > Has anyone been thinking of tweaking the ports "extract" target > > to copy from a local copy of the original repository, rather > > than going straight for a tarball file? > > > > How could we standardise access to source repositories from > > different vendors, so that the ports makefiles could determine > > if they were present automagically? > > > > Would it be best to go for full local CVS repositories, and have > > the "extract" target do a cvs co, or could we get by with local > > "checked-out" trees? (I haven't really used CVS myself yet: I > > follow FreeBSD-stable with CVSup in "check out" mode.) > > If I understand you correctly, you are proposing to keep extracted from > distfiles stuff in some sort of anoncvs repository, which will simplify > incremental updates of 3rd party software for the users with limited bandwidth > available, so for example when upgrading from the XFree4.0.1 to XFree4.0.2 the > user will be saved from the necessity to d/l the whole 40-some megabytes > archive, and will need to only update his existing XFree86 sources using `cvs > update' command. While this idea in general sounds good, but I think that the > cost involved for keeping code of each of our 4200+ ports in cvs is just too > high (remember, this repo will be growing with insane speed with each update of > underlying software). > > The another possibility that I'm thinking about now is to set up a service > which at a specific request will generate xdelta(1) patch for any two arbitrary > versions of distfiles (for example bzip'ed version of xdelta-generated diff > between XFree4.0.1 and XFree4.0.2 distfiles is only 3MB long). Then the user > will be able to download only the difference between two versions in question > and apply diff to his local existing previous versions of software. Popular > diffs could be cached at the "server", as the creating xdelta diffs for large > files is io/cpu consuming task. The only problem with this schema is that the > xdelta(1) can't reconstruct gzipped tarball in such a way that the md5 sum for > original archive and md5 sum for reconstructed will match (however checksums of > underlying tar files will be equial), so we need some form of a workaround here > (for example use two md5 entries for each file in distinfo - gzip'ed and > gunzip'ed). > > As I said it's only the idea right now, but I'm close to starting implementing > something like that because internet costs are insanely high here ;). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001221175227.B7974>