Re: [gentoo-dev] cvs.eclass: build while being offline

[Dan Armak]

On Wednesday 10 March 2004 02:54, Thomas de Grenier de Latour wrote:
> On Tue, 09 Mar 2004 12:36:17 -0800
>
> Jason Rhinelander <jason@××××××××××××××××.com> wrote:
> > How is that broken behaviour?  If a non-cvs ebuild can't download its
> > sources, it fatals as well.
>
> The difference is that with usual ebuilds, you can "emerge -f" from your
> laptop when it's connected for instance at your work, or download
> source archives from a friend's computer and use a removable device,
> etc.  There are a lot of such workaround that make _possible_ to use
> ebuilds for people who don't have internet at home, but none of the
> usual and simple ones apply to cvs ebuilds because they fetch at
> src_unpack time.  Not really a broken behavior tho, but may be annoying
> for some people.  Also, the fact that you have to cvs update when you do
> a revdep-rebuild despite you've not deleted anything from your distfiles
> is a unexpected behavior.  Maybe the eclass could take a CVS_NO_UPDATE
> environnement variable into account that would force the ebuild to use
> the repository in its current state instead of updating?  That would
> easily solve the above issues.

There's already such a setting: ECVS_SERVER="offline" forces the eclass to use 
an existing checkout dir. You can use ebuild foo.ebuild unpack, or just run 
cvs checkout/update manually, to get the sources beforehand. A lot less 
comfortable than emerge -f, but nothing can be done on the eclass side since 
fetch isn't overloadable anymore :-(

What the orig poster wants is a fallback to this behaviour when offline 
regardless of ECVS_SERVER settings.

An interesting general solution, which also allows for CVS mirrors (possibly 
useful for eg KDE), is to make ECVS_SERVER multi-value. The eclass would try 
to fetch from each location until the cvs command succeeded. "offline" could 
then be specified as a last value for fallback.

That's just an idea off the top of my head, not thought through, so there's 
probably some reason it isn't good. Opinions?

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951