Re: [gentoo-dev] new repoman check

[Alec Warner]

Harald van Dijk wrote:
> 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.
>
>

The error has been dropped to a warning, repoman will presently complain 
for any ebuild which has stable keywords and inherits a "VCS" eclass. 
Repoman will then list off all the arches that are keyworded stable.

*In General* Inheriting a VCS eclass and having stable keywords means 
you are doing something wrong, there are exceptions; thats why warning 
is important here (more effective than an error as I think more about 
it).  It's a warning to allow exceptions, expect the QA team to nudge 
you about ebuilds with odd keywording though.

I am attempting to enforce current devrel policy with this change.  I 
will push for policy to be changed later to pmask as I think that is the 
proper way to go about things.  However that is seperate discussion.

-- 
gentoo-dev@g.o mailing list