How to check out ports

Wed Oct 3 11:21:54 UTC 2012

On Tue, 02 Oct 2012 21:54:31 -0500
Paul Schmehl <pschmehl_lists at tx.rr.com> wrote:

> --On October 2, 2012 11:28:12 PM +0200 Michael Gmelin
> <freebsd at grem.de> wrote:
> 
> >
> >
> > On Tue, 02 Oct 2012 14:14:26 -0500
> > Paul Schmehl <pschmehl_lists at tx.rr.com> wrote:
> >
> >> --On October 2, 2012 2:44:46 PM -0400 Eitan Adler
> >> <lists at eitanadler.com> wrote:
> >> > On 2 October 2012 14:37, Paul Schmehl <pschmehl_lists at tx.rr.com>
> >> > wrote:
> >> >> I obviously wasn't very clear.  I'm a port maintainer.  I need
> >> >> to update one of my ports.  I used to do this by checking out
> >> >> the port into a purpose-created directory in which I would use
> >> >> cvs to make changes and test. After everything checked out, I
> >> >> would submit the diff.
> >> >
> >> > We need to be better about announcing these changes as not to
> >> > frustrate maintainers. :)
> >> >
> >> >> Now cvs isn't working, so how, as a port maintainer, do I check
> >> >> out a single port so I can update it and submit it in a PR?
> >> >
> >> > You should do things the same way you did before, but instead you
> >> > should use svn to checkout out your port. Note that 'module
> >> > names' no longer work so you must use the full name:
> >> > e..g., svn checkout svn://svn.freebsd.org/ports/head/editors/nano
> >> >
> >> > It may help to keep a folder of "ports-I-maintain" with the ports
> >> > you maintain checked out. Before you update them do "svn update
> >> > *" and to generate a diff do "svn diff foldername"
> >> I got on the wiki and figured out how to check ou the port using
> >> svn, but now I'm stuck again.  This port has moved to github, and
> >> I don't have a clue how to download it in the Makefile.  There's
> >> no mention of github in /usr/ports/Mk, so I assume the method
> >> hasn't even been written yet. The source is here:
> >> <https://github.com/firnsy/barnyard2/>, but I don't see a tarball,
> >> and I don't know enough about ports to know if it's even possible
> >> to fetch it from github.
> >
> > Hi Paul,
> >
> > What about using the ZIP
> >
> > https://github.com/firnsy/barnyard2/zipball/master
> >
> > (this will give you the current master branch in a ZIP file)
> >
> > or a tarball
> >
> > https://github.com/firnsy/barnyard2/tarball/master
> >
> > If you want to keep things more stable (since the master branch
> > might change frequently and break your build), limit yourself to a
> > specific version. Fortunately this software is using tags for
> > versioning, so it's easy to get zips from github, e.g.:
> >
> > https://github.com/firnsy/barnyard2/zipball/v2-1.10
> >
> > or if you prefer a tarball (which is usually nicer to have)
> >
> > https://github.com/firnsy/barnyard2/tarball/v2-1.10
> >
> > Github provides tarballs (and zipballs) for all branches and tags.
> >
> > See also:
> >
> > https://github.com/blog/12-tarball-downloads
> >
> > Hope that helps
> 
> How do I handle this?
> 
> firnsy-barnyard2-v2-1.10-0-g2f5d496.tar.gz
> 
> Is the string at the end (g2f5d496) auto-generated?  If so, that's
> another problem.
> 
> I guess something like this?  Sheesh.  What a PITA.
> 
> PORTNAME=       barnyard2-v2
> PORTVERSION=    1.10
> PKGNAMEPREFIX=  firnsy-
> PKGNAMESUFFIX=  -0-g2f5d496
> 

The file name is the result of the command "git describe" and is
therefore stable. It consists of three parts:

tag - number of commits - commit hash

This project uses tags for versioning (which makes sense), so this file
name tells you that you're dealing with version v2-1.10, there have
been no commits to the tree since this version (it's unaltered) and the
commit id is g2f5d496 (which is a short but unique version of the
original sha1). You can use this commit id to get exactly this version
from a git repository (git clone ...; git checkout g2f5d496). If
somebody commited to the repository, the number in the middle would
increase and the hash change - but this will not happen in this
scenario, since github creates the tarball by checking out the tag (git
clone ...; git checkout v2-1.10), so as long as the project owner
doesn't change the meaning of the tag (which he usually won't since he
would redefine what vesion v2-1.10 means) this file name is stable.

That said, when you're fetching using the fetch command (this is
what ports uses) things look different anyway. Let's assume you're
fetching a tag (= a version) and not master (which is not a version, but
basically the current stable environment) and you're using the fetch
program to get it, then the resulting file name is NOT
firnsy-barnyard2-v2-1.10-0-g2f5d496.tar.gz but "v2-1.10".

[dev at bsd64 /tmp]$ fetch
https://github.com/firnsy/barnyard2/tarball/v2-1.10
v2-1.10                                       100% of  409 kB  414 kBps
...

Like Eitan pointed out, fortunately there are github supporting options
in bsd.ports.mk. So if you use the following settings you should be fine
(just tested this here and ended up creating an almost complete port
skeleton - I turned v2-1.10 into 2.1.10 in the process, since v2-1.10
would not be supported by the ports system - so this installs as
barnyard2-2.1.10, which should be ok for future updates).

Makefile:
# Whom:		pschmehl_lists at tx.rr.com
# $FreeBSD:$
#

PORTNAME=	barnyard2
PORTVERSION=	2.1.10
CATEGORIES=	security
GH_ACCOUNT=	firnsy
GH_PROJECT=	barnyard2
GH_TAGNAME=	v2-1.10
GH_COMMIT=	2f5d496
USE_GITHUB=     YES
GNU_CONFIGURE=	yes
MAKE_JOBS_UNSAFE=YES

MAINTAINER=	pschmehl_lists at tx.rr.com
COMMENT=	Barnyard2 is a dedicated spooler\
		for Snorts unified2 binary output format. 

pre-configure:
	cd ${WRKSRC}; ${SH} autogen.sh

.include <bsd.port.mk>

distinfo:
SHA256 (barnyard2-2.1.10.tar.gz) = 31d4e3745606489658bd411f74ffeb8a27573fdc08d0b51a6a71e1bf4dece8a2
SIZE (barnyard2-2.1.10.tar.gz) = 419781

pkg-descr:
Barnyard2 is a dedicated spooler for Snort's
unified2 binary output format.

https://github.com/firnsy/barnyard2/

pkg-plist:
bin/barnyard2
etc/barnyard2.conf

I attached the full port skeleton in a tarball, it might need some
checking, I just did the usual (make install, make reinstall,
pkg_create, pkg_delete).

Maybe somebody could use this information to create a page about using
github in the porter's handbook (it won't be me :D)?

Cheers,
Michael

-- 
Michael Gmelin