Re: [gentoo-dev] new repoman check

[Brian Harring]

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