[gentoo-dev] new repoman check

[gentoo-dev] new repoman check

[Alec Warner]

Slipping this in before 2.1 goes stable, it's a small check.

Basically if your ebuild inherits a VCS eclass ( currently darcs, 
subversion, cvs ) AND your ebuild has stable keywords on any arches 
repoman will report an error.

One thing to note here:

Are there any cases when one inherits a VCS eclass but the ebuild itself 
is not a live checkout ebuild.

I don't see any, looking at the eclasses.

This repoman check attempts to enforce policy in the developer handbook[1].

""Live" cvs.eclass ebuilds are generally only intended for the 
convenience of developers and should always be masked with a ~[arch] 
keyword. It is impossible to guarantee the reliability of a "live" 
cvs.eclass ebuild since the upstream cvs tree may change at any time, 
which is why they should always be masked.

Whether a "live" CVS ebuild or a "snapshot" CVS ebuild, you the 
developer are responsible for ensuring that the ebuild works correctly. 
This is particularly difficult to do with "live" cvs ebuilds for obvious 
reasons."

[1]http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Harald van Dijk]

On Sun, Jun 04, 2006 at 04:09:44PM -0400, Alec Warner wrote:
> Slipping this in before 2.1 goes stable, it's a small check.
> 
> Basically if your ebuild inherits a VCS eclass ( currently darcs, 
> subversion, cvs ) AND your ebuild has stable keywords on any arches 
> repoman will report an error.
> 
> One thing to note here:
> 
> Are there any cases when one inherits a VCS eclass but the ebuild itself 
> is not a live checkout ebuild.
> 
> I don't see any, looking at the eclasses.

Some gnustep stuff inherits cvs, but uses -D in the cvs options to
always download exactly the same thing.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] new repoman check

[Harald van Dijk]

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

Re: [gentoo-dev] new repoman check

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] new repoman check

[Harald van Dijk]

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

Re: [gentoo-dev] new repoman check

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Ciaran McCreesh]

On Mon, 5 Jun 2006 11:56:16 +0200 Harald van Dijk <truedfx@gentoo.org>
wrote:
| 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.

It's not a hard ban because when I wrote it I was thinking that maybe
some day someone would come up with a legitimate reason for it. You've
yet to do that, so you don't get to take the exception clause.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

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@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Harald van Dijk]

On Mon, Jun 05, 2006 at 12:57:08PM +0100, Ciaran McCreesh wrote:
> On Mon, 5 Jun 2006 11:56:16 +0200 Harald van Dijk <truedfx@gentoo.org>
> wrote:
> | 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.
> 
> It's not a hard ban because when I wrote it I was thinking that maybe
> some day someone would come up with a legitimate reason for it. You've
> yet to do that, so you don't get to take the exception clause.

The proposal was to change it to a hard ban. You say that there could
be legitimate reasons for (un)stable CVS ebuilds. What I'm saying is
that they're valid from a portage POV even without reasons, that they're
currently used, and that the current stable CVS ebuilds are indeed a bad
idea. So far, I don't think you disagree, but if you do, please explain.

I then said that *you* say there can be legitimate reasons for them. So
why do *I* have to come up with examples of it?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Ciaran McCreesh]

On Mon, 5 Jun 2006 14:41:43 +0200 Harald van Dijk <truedfx@gentoo.org>
wrote:
| I then said that *you* say there can be legitimate reasons for them.
| So why do *I* have to come up with examples of it?

Well that's just it. I didn't say there were legitimate reasons, I just
didn't commit myself to saying that there weren't.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Harald van Dijk]

On Mon, Jun 05, 2006 at 01:51:31PM +0100, Ciaran McCreesh wrote:
> On Mon, 5 Jun 2006 14:41:43 +0200 Harald van Dijk <truedfx@gentoo.org>
> wrote:
> | I then said that *you* say there can be legitimate reasons for them.
> | So why do *I* have to come up with examples of it?
> 
> Well that's just it. I didn't say there were legitimate reasons, I just
> didn't commit myself to saying that there weren't.

Fair enough, but if you read "can" as "could" in my posts, they still
make sense.

Two reasons for CVS ebuilds that aren't hardmasked, by the way:

One: see emacs-cvs-22*; it's more reliable than the emacs-22* snapshot.
     (Something like this is only for ~arch.)
Two: when a specific revision is wanted, but snapshots aren't possible
     for legal reasons. (This could even be marked stable.)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new repoman check

[Ned Ludd]

On Mon, 2006-06-05 at 15:16 +0200, Harald van Dijk wrote:
> On Mon, Jun 05, 2006 at 01:51:31PM +0100, Ciaran McCreesh wrote:
> > On Mon, 5 Jun 2006 14:41:43 +0200 Harald van Dijk <truedfx@gentoo.org>
> > wrote:
> > | I then said that *you* say there can be legitimate reasons for them.
> > | So why do *I* have to come up with examples of it?
> > 
> > Well that's just it. I didn't say there were legitimate reasons, I just
> > didn't commit myself to saying that there weren't.
> 
> Fair enough, but if you read "can" as "could" in my posts, they still
> make sense.
> 
> Two reasons for CVS ebuilds that aren't hardmasked, by the way:
> 
> One: see emacs-cvs-22*; it's more reliable than the emacs-22* snapshot.
>      (Something like this is only for ~arch.)

> Two: when a specific revision is wanted, but snapshots aren't possible
>      for legal reasons. (This could even be marked stable.)

If it can't be checksummed it should never be marked stable. *VCS* 
ebuilds simply can't be checksumed and there are far to many ways 
to abuse such things. Think MiM

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list