On Mon, Jun 05, 2006 at 01:54:08AM -0700, Brian Harring wrote:
> On Mon, Jun 05, 2006 at 10:19:41AM +0200, Harald van Dijk wrote:
> > On Mon, Jun 05, 2006 at 03:45:50AM -0400, Mike Frysinger wrote:
> > > On Monday 05 June 2006 02:07, Harald van Dijk wrote:
> > > > Some gnustep stuff inherits cvs, but uses -D in the cvs options to
> > > > always download exactly the same thing.
> > > 
> > > then arent you just adding overhead to the poor gnustep cvs servers ?  
> > > why not 
> > > roll a cvs snapshot tarball and distro via our mirrors
> > 
> > Yeah, that'd probably be a better idea, but even if the current ebuilds
> > are less than perfect, it seems like a valid use of the eclass to me, so
> > making repoman error out is a bad idea, I think. A warning would be
> > useful, though.
> 
> 'Cept standards for ebuilds is typically http/https/ftp access for 
> fetching files- forcing pserver means people behind firewalls are 
> screwed... which is why non standard uri that is generally accessible 
> to users must be http/https/ftp, and if they aren't, upload the file 
> to the mirrors.
> 
> Ebuilds might work, don't think they qualify as valid though- assume 
> initially it was easier to just copy the ebuild and lock the date; 
> doesn't make it valid though. :)

I now checked:

http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html

If it's explained how to do it in the docs, I consider it valid,
regardless of how bad an idea it may be.

> Should be an error imo- there isn't any real requirement for a 
> cvs/git/darcs/subversion eclass consumer to be visible really.
> ~harring

Are you hoping for even ~arch cvs ebuilds to cause a repoman error?
-- 
gentoo-dev@gentoo.org mailing list

Reply via email to