[gentoo-dev] ebuild policy questions.

[gentoo-dev] ebuild policy questions.

[Terje Kvernes]

  hi all, thanks for a great distro!

  now, I'm in the process of trying to contribute a little, in effect
  making some ebuilds.  now, the technical writing of the builds isn't
  a problem, yet, it's more a few things I wonder about policy-wise.

  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?

  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?

  anyhow, thanks for your time, hopefully you won't need to thump my
  head too many times in the future.

-- 
Terje - a very happy Gentoo-user, hopefully contributing a little
        eventually.

Re: [gentoo-dev] ebuild policy questions.

[Tod M. Neidt]

Hi!

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. 

On Thu, 2002-04-11 at 15:30, Terje Kvernes wrote:
> 
>   hi all, thanks for a great distro!
> 
>   now, I'm in the process of trying to contribute a little, in effect
>   making some ebuilds.  now, the technical writing of the builds isn't
>   a problem, yet, it's more a few things I wonder about policy-wise.
> 
>   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.  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.

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.

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.

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

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.

Contributions are always welcome and appreciated.

Hope that helps,

tod

Re: [gentoo-dev] ebuild policy questions.

[Terje Kvernes]

"Tod M. Neidt" <tod@gentoo.org> 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

Re: [gentoo-dev] ebuild policy questions.

[Tod M. Neidt]

Hi Terje!

I should have explicitly discussed the distinction between upstream and
third-party patches and those that are specific to Gentoo Linux.  I
assumed that we were talking about the former in my previous post.

Normally gentoo specific patches created by the ebuild author are kept
in the files directory.  A suffix of "-gentoo" is typically appended to
indicate this.  For example, xgammon-0.98-gentoo-makefile.patch, or
something to that effect.

Sorry for any confusion that this may have caused.

Regards,

tod

On Fri, 2002-04-12 at 05:27, Terje Kvernes wrote:



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

Re: [gentoo-dev] ebuild policy questions.

[Terje Kvernes]

"Tod M. Neidt" <tod@gentoo.org> writes:

> Hi Terje!

  hi Tod.  :)
 
> I should have explicitly discussed the distinction between upstream
> and third-party patches and those that are specific to Gentoo Linux.
> I assumed that we were talking about the former in my previous post.

  I didn't think much of the difference to be honest.  but thanks for
  clearing it up.
 
> Normally gentoo specific patches created by the ebuild author are
> kept in the files directory.  A suffix of "-gentoo" is typically
> appended to indicate this.  For example,
> xgammon-0.98-gentoo-makefile.patch, or something to that effect.

  oki.  I'll keep that in mind when writing patches.
 
> Sorry for any confusion that this may have caused.

  stop being sorry for helping.  ;)

-- 
Terje