Re: [gentoo-dev] ebuild policy questions.

[Terje Kvernes]

"Tod M. Neidt" <tod@g.o> writes:

> Hi!

  arp.  :)
 
> I'll take a stab at this and offer some suggestions.  Please note
> that these comments should not be considered "policy" and it should
> be a given that any drobbins pronouncements on this issue
> automatically trump mine.

  okidoki.  thanks. 
 
> On Thu, 2002-04-11 at 15:30, Terje Kvernes wrote:
>
>  [ ... ]
>
> > first off, if I see an ebuild that is out of date, do I contact
> > the author of the out-of-date ebuild or do I submit a new one?  so
> > far I've thought "if the old one is _really_ out of date, I'll
> > submit a new ebuild, if it's a week or two since the new version
> > came out, I'll take it with the author."  the real question is
> > probably how "possessive" authors are / are supposed to be with
> > regards to their ebuilds.  is there any set policy on this?
>
> I would suggest submitting any changes to bugzilla and notifying the
> "author" or "maintainer" by cc'ing them on the bug submission if
> they don't happen to be the automatic assignee.

  good point.

> Note that you should probably check the Changelog for that
> particular package to see who has been actively maintaining the
> ebuild, as this developer is not necessarily the same as the one
> listed in the ebuild header.

  that much I figured on my own, but it is none the less good advice.
  besides, this happens to be stored in the list archives, so
  additional information is always a good thing[tm].
 
> If the ebuild update just requires a copy of the ebuild to the new
> revision number, it is not necessary to attach the ebuild.  A
> comment stating that "version 1.2 of foo has been released,a simple
> copy of foo-1.1-r3.ebuild to foo-1.2.ebuild works" or something to
> that effect is sufficient.

  oki.
 
> If the ebuild update requires changes to the ebuild, I find it
> convenient when people attach a diff between the original and
> updated ebuild instead of the entire updated ebuild as this makes it
> very easy to see the changes that are proposed.

  good point again.  I wasn't all that comfortable with creating diffs
  until I wrote the xgammon ebuild yesterday.  then I didn't have much
  choice.  :)
 
> > second, and a bit more tricky.  I thought I'd make an xgammon
> > ebuild.  all fine and dandy, but there are a few patches (from
> > RedHat) to xgammon which are nice to have (they fix minor bugs --
> > void main -> int main and a few other things).  what to do?  if I
> > include the patches, how do I link to them?  or do I just put them
> > in the "files"-directory with the ebuild?
>
> For patch files (especially large ones) include the URL to the patch
> in the SRC_URI string so that it will be downloaded with the source
> tarball and stored in ${DISTDIR}, i.e. /usr/portage/distfiles by
> default.  See the dev-lang/python ebuild for a good example (In fact
> the python ebuild is a good example for a variety ebuild techniques
> for uncommon situations)

  hm.  the patches I need total about 1K, and I _could_ host the
  patches via http.
 
> If the patch files are small (working definition of small not much
> larger than the ebuild itself), placing them in the files directory
> is ok, but the former method is prefereable.

  okay, I'll try getting them to work via http.  <pause for half an
  hour>.  okay, done.  :)  now just to check that things work and
  submit.  should I attach the patches as well?
 
> Contributions are always welcome and appreciated.

  considering how much the Gentoo community (well, the linux community
  in general actually) has given me I feel bad for not contributing
  more than I do.  :/
 
> Hope that helps,

  always, thank you.

-- 
Terje