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
