On Mon, Jun 05, 2006 at 11:14:45AM +0200, Harald van Dijk wrote: > 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.
Except the doc specifically states they should be package.mask'd if added; what that doc is talking about is vcs head ebuilds, not an ebuild that's locked down to an exact rev/date. As mike said, why hammer on their servers? The ebuild isn't changing (it's effectively a locked version), tarball it and upload it. Basically, the locked cvs version ebuild referenced above seems like a lazy trick someone did to avoid rewriting it to drop the cvs usage. > > 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? Original rules *were* that no vcs head based ebuild should be visible, that it must be masked. Current devrel docs contradict that (those docs bluntly are wrong- that change I don't think anyone ever agreed to), devmanual states it correctly. There's nothing wrong with vcs head ebuilds if they're masked; if they're user visible (~arch), there is _no_ way to gurantee they're actually sane (the source can and does change), that's why they're suppossed to be masked. ~harring
pgpWrYhXCDvQj.pgp
Description: PGP signature
