On Sat, 2 Jun 2007 11:41:01 +0200
Klaus Heinz <k.heinz.jun.sieben%kh-22.de@localhost> wrote:
>
> You have already managed the most important aspect: you volunteered to do
> it :-)
>
> Seriously, in order to maintain a package in pkgsrc you should have a
> basic understanding of how to build software from source and how to do
> that in the context of pkgsrc. For the latter you can read the pkgsrc
> guide, as you have done. Any open technical questions about maintenance
> of a package can always be asked on tech-pkg.
So far so good.
>
> Joining the pkgsrc-wip project (see <http://pkgsrc-wip.sourceforge.net/>)
> can also help you. If you want to have the bleeding edge of the
> software, which may not be suitable for pkgsrc itself due to stability
> reasons, pkgsrc-wip is the ideal place to work on the package.
I just might do that.
>
> Using the software, at least occasionally, is very helpful in case there
> are bugs. If those bugs are reported to the GNATS tracking system
> (pkgsrc-bugs), they will be assigned to you.
> You should try to determine whether the bug is related to pkgsrc
> or originates in the software itself. Bugs related to pkgsrc should be
> fixed, with help from the community if necessary.
> For a bug not caused by pkgsrc you will probably contact the original
> authors ("upstream") to see whether this is a known defect.
> If your are able to fix such problems, so much the better, but you are
> certainly _not required_ to do that, which may be really hard sometimes.
In this case I use PyGopherd to run my own Gopher server, so I'm already using
it day in and day out. Seeing that the version that's available was ahead of
the version in pkgsrc and that it has been for so long is what motivated me to
want to maintain this package since I figured no one else would.
I've already tried building the newest version, which is 2.0.16, not 2.0.13 as
I originally thought, using pkgsrc. I copied the net/pygopherd directory to a
directory called local/pygopherd, downloaded the new source file, changed the
Makefile and distinfo to reflect the new version, and tried to build it. It
worked without a hitch. I guess I got lucky, but the info on bugs is good to
know in case it does change.
>
> If building the software in pkgsrc needs any patches they should be fed
> back upstream for integration into the next official release, provided
> they are general enough to be valuable to them (ie, not directly caused
> by some feature of pkgsrc). In my experience, authors will accept
> patches if they are created in a way that impacts builds on non-pkgsrc
> systems either not at all or in a very minor way.
> Making the software authors aware of the package being available in
> pkgsrc is also a nice way of advertising pkgsrc :-).
I have little programming experience (some Python and Java, no C) so I think I
may need assistance with creating any patches that may be needed in the future.
>
> You mentioned two points you want to do right away:
> - Updating the software to the current version
>
> The update is a task expected of the maintainer. The package in pkgsrc
> should be a current and stable version of the software, if at all
> possible for all the supported platforms.
Assuming I didn't overlook anything I think I've pretty much done this. All I
would need to do is feed it back into the pkgsrc tree.
>
> - Getting it to work with Python 2.4
>
> If the software itself has problems with Python 2.4 then this is
> something you _can_ do if you want to, but it is not something I would
> expect of a maintainer.
> If the problem is somehow related to pkgsrc it should be fixed by the
> maintainer.
I haven't touched this yet. That will be something I'll try next.
>
> There is one negative aspect of being the maintainer: Be prepared that
> the e-mail address you provide for the MAINTAINER field will be widely
> known and probably abused by spammers.
Bring it on. :)
- Dave V.
Attachment:
pgpJA321m_gFm.pgp
Description: PGP signature