Re: [gentoo-dev] new repoman check

[Harald van Dijk]

On Mon, Jun 05, 2006 at 02:24:24AM -0700, Brian Harring wrote:
> 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.

It first lists the disadvantages of CVS sources in general, and then
the disadvantages of live CVS sources. If it only applied to live CVS
sources, why would it split them up?

> As mike said, why hammer on their servers?  The ebuild isn't changing
> (it's effectively a locked version), tarball it and upload it.

And as I said, I agree that that would be a better idea.

> 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.

The devmanual states that they should not "generally" be added to the
tree softmasked or unmasked. It does not state that they should never
be added as such at all. Or, in other words, there can be exceptions.

> 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
-- 
gentoo-dev@g.o mailing list