bsdiff: convert ebuild to the new eclass format

bsdiff: convert ebuild to the new eclass format

Portage automatically uses an overlay ebuild of the same name, so it suffices to copy and modify the original ebuild.

[adlr, 2010-06-11 06:28:43]

keep in mind that these bsdiff files were modified by me. we may want to
revert the files to the original format and have a patch file for the mods
that we made (which are likely not upstreamable).

-andrew

On Thu, Jun 10, 2010 at 7:28 PM, <zbehan@chromium.org> wrote:

> Reviewers: anush, Mandeep Singh Baines, adlr,
>
> Description:
> bsdiff: convert ebuild to the new eclass format
>
> Please review this at http://codereview.chromium.org/2779016/show
>
> SVN Base: ssh://gitrw.chromium.org/chromiumos-overlay
>
> Affected files:
>  M dev-util/bsdiff/bsdiff-4.3-r1.ebuild
>  A dev-util/bsdiff/bsdiff-9999.ebuild
>
>
> Index: dev-util/bsdiff/bsdiff-4.3-r1.ebuild
> diff --git a/dev-util/bsdiff/bsdiff-4.3-r1.ebuild
> b/dev-util/bsdiff/bsdiff-4.3-r1.ebuild
> index
>
bb3b899866ac1ecab6b870dccb50638adcfb51ee..f6f875196e742642dad50652fcec60db50bfe891
> 100644
> --- a/dev-util/bsdiff/bsdiff-4.3-r1.ebuild
> +++ b/dev-util/bsdiff/bsdiff-4.3-r1.ebuild
> @@ -2,7 +2,7 @@
>  # Distributed under the terms of the GNU General Public License v2
>  # $Header: /var/cvsroot/gentoo-x86/dev-util/bsdiff/bsdiff-4.3-r1.ebuild,v
> 1.12 2010/01/15 21:21:10 fauli Exp $
>
> -inherit toolchain-funcs flag-o-matic
> +inherit toolchain-funcs flag-o-matic cros-workon
>
>  IUSE=""
>
> @@ -16,17 +16,10 @@ KEYWORDS="alpha amd64 arm hppa ia64 mips ppc sparc x86
> ~x86-fbsd ~x86-freebsd ~a
>  DEPEND="app-arch/bzip2"
>  RDEPEND="${DEPEND}"
>
> -src_unpack() {
> -       local third_party="${CHROMEOS_ROOT}/src/third_party"
> -       elog "Using third_party: $third_party"
> -       mkdir -p "${S}"
> -       cp -a "${third_party}/bsdiff/files"/* "${S}" || die
> -}
> -
>  src_compile() {
>        append-lfs-flags
> -       $(tc-getCC) ${CFLAGS} ${LDFLAGS} -o bsdiff bsdiff.c -lbz2 || die
> "failed compiling bsdiff"
> -       $(tc-getCC) ${CFLAGS} ${LDFLAGS} -o bspatch bspatch.c -lbz2 || die
> "failed compiling bspatch"
> +       $(tc-getCC) ${CFLAGS} ${LDFLAGS} -o bsdiff files/bsdiff.c -lbz2 ||
> die "failed compiling bsdiff"
> +       $(tc-getCC) ${CFLAGS} ${LDFLAGS} -o bspatch files/bspatch.c -lbz2
> || die "failed compiling bspatch"
>  }
>
>  src_install() {
> Index: dev-util/bsdiff/bsdiff-9999.ebuild
> diff --git a/dev-util/bsdiff/bsdiff-9999.ebuild
> b/dev-util/bsdiff/bsdiff-9999.ebuild
> new file mode 100644
> index
>
0000000000000000000000000000000000000000..8f0ff87667d9e55aee0bede69e300c8796e365c4
> --- /dev/null
> +++ b/dev-util/bsdiff/bsdiff-9999.ebuild
> @@ -0,0 +1,28 @@
> +# Copyright 1999-2010 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: /var/cvsroot/gentoo-x86/dev-util/bsdiff/bsdiff-4.3-r1.ebuild,v
> 1.12 2010/01/15 21:21:10 fauli Exp $
> +
> +inherit toolchain-funcs flag-o-matic cros-workon
> +
> +IUSE=""
> +
> +DESCRIPTION="bsdiff: Binary Differencer using a suffix alg"
> +HOMEPAGE="http://www.daemonology.net/bsdiff/"
> +
> +SLOT="0"
> +LICENSE="BSD-2"
> +KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~sparc ~x86 ~x86-fbsd
> ~x86-freebsd ~amd64-linux ~x86-linux ~ppc-macos"
> +
> +DEPEND="app-arch/bzip2"
> +RDEPEND="${DEPEND}"
> +
> +src_compile() {
> +       append-lfs-flags
> +       $(tc-getCC) ${CFLAGS} ${LDFLAGS} -o bsdiff files/bsdiff.c -lbz2 ||
> die "failed compiling bsdiff"
> +       $(tc-getCC) ${CFLAGS} ${LDFLAGS} -o bspatch files/bspatch.c -lbz2
> || die "failed compiling bspatch"
> +}
> +
> +src_install() {
> +       dobin bs{diff,patch}
> +       doman bs{diff,patch}.1
> +}
>
>
>

[zbehan, 2010-06-11 16:56:05]

On 2010/06/11 06:28:43, adlr wrote:
> keep in mind that these bsdiff files were modified by me. we may want to
> revert the files to the original format and have a patch file for the mods
> that we made (which are likely not upstreamable).

I think that was the whole point. Are you saying that bsdiff will not be ever
again actively worked on, and can actually become a regular ebuild patched on
top of the official version?

[adlr, 2010-06-11 17:29:59]

So, more specifically, bsdiff is unchanged. bspatch was changed in a few
places.

I think in general we are going to want to keep upgrading to the latest
version of bsdiff and making sure we can apply the patch of our changes to
it.

So yeah, maybe we should just revert to the original ebuild and use a patch
file.

-andrew

On Fri, Jun 11, 2010 at 9:56 AM, <zbehan@chromium.org> wrote:

> On 2010/06/11 06:28:43, adlr wrote:
>
>> keep in mind that these bsdiff files were modified by me. we may want to
>> revert the files to the original format and have a patch file for the mods
>> that we made (which are likely not upstreamable).
>>
>
> I think that was the whole point. Are you saying that bsdiff will not be
> ever
> again actively worked on, and can actually become a regular ebuild patched
> on
> top of the official version?
>
>
> http://codereview.chromium.org/2779016/show
>

[zbehan, 2010-06-11 17:45:21]

That means that you'd have to actively follow the ebuilds in the official tree
and whenever new stable version comes up, you replace it with _p1 of your own,
including the patches, which might have to be ported.

I'd probably suggest to keep it in git, and once in a while pull in the upstream
changes and rebase on top of it. It might be a lot more convenient for you. Ie.
keep the proposed layout of a live-9999 ebuild and stable-x.y.z autoincremented
with each change in git.

Since it's probably you who's going to be doing that, you decide, but if you
think patch is the way, it would be useful if you patchified your changes,
removed the sources from DEPS, and created the new ebuild as part of the
transition process, replacing this CL, with the cleanup operations like removing
source not being a priority.

Anush or msb may have more to say to this.

On 2010/06/11 17:29:59, adlr wrote:
> So, more specifically, bsdiff is unchanged. bspatch was changed in a few
> places.
> 
> I think in general we are going to want to keep upgrading to the latest
> version of bsdiff and making sure we can apply the patch of our changes to
> it.
> 
> So yeah, maybe we should just revert to the original ebuild and use a patch
> file.
> 
> -andrew

[adlr, 2010-06-11 17:53:14]

If you want to keep it in git, that's fine. We probably want to be careful
about upgrades anyway.

-andrew

On Fri, Jun 11, 2010 at 10:45 AM, <zbehan@chromium.org> wrote:

> That means that you'd have to actively follow the ebuilds in the official
> tree
> and whenever new stable version comes up, you replace it with _p1 of your
> own,
> including the patches, which might have to be ported.
>
> I'd probably suggest to keep it in git, and once in a while pull in the
> upstream
> changes and rebase on top of it. It might be a lot more convenient for you.
> Ie.
> keep the proposed layout of a live-9999 ebuild and stable-x.y.z
> autoincremented
> with each change in git.
>
> Since it's probably you who's going to be doing that, you decide, but if
> you
> think patch is the way, it would be useful if you patchified your changes,
> removed the sources from DEPS, and created the new ebuild as part of the
> transition process, replacing this CL, with the cleanup operations like
> removing
> source not being a priority.
>
> Anush or msb may have more to say to this.
>
>
> On 2010/06/11 17:29:59, adlr wrote:
>
>> So, more specifically, bsdiff is unchanged. bspatch was changed in a few
>> places.
>>
>
>  I think in general we are going to want to keep upgrading to the latest
>> version of bsdiff and making sure we can apply the patch of our changes to
>> it.
>>
>
>  So yeah, maybe we should just revert to the original ebuild and use a
>> patch
>> file.
>>
>
>  -andrew
>>
>
> http://codereview.chromium.org/2779016/show
>

[zbehan, 2010-06-11 18:04:43]

On 2010/06/11 17:53:14, adlr wrote:
> If you want to keep it in git, that's fine. We probably want to be careful
> about upgrades anyway.

I don't have a preference here, I'm just converting the ebuild. :)

Anyway, in the event that we want to stop all upstream updates, it would be
better if the ebuild received a version of something like "9998", which will
never be overridden with any of the official ebuilds. Or the package can be
renamed to be disjoint.

[anush, 2010-06-11 18:19:44]

For small patchsets if we can avoid an additional git repo and just
have it in the ebuild itself it will be the preferred way, since we
will patch 100s of ebuilds.

On Fri, Jun 11, 2010 at 11:04 AM,  <zbehan@chromium.org> wrote:
> On 2010/06/11 17:53:14, adlr wrote:
>>
>> If you want to keep it in git, that's fine. We probably want to be careful
>> about upgrades anyway.
>
> I don't have a preference here, I'm just converting the ebuild. :)
>
> Anyway, in the event that we want to stop all upstream updates, it would be
> better if the ebuild received a version of something like "9998", which will
> never be overridden with any of the official ebuilds. Or the package can be
> renamed to be disjoint.
>
> http://codereview.chromium.org/2779016/show
>

[zbehan, 2010-06-11 20:02:29]

OK! I'll prepare the new ebuild then.

On 2010/06/11 18:19:44, anush wrote:
> For small patchsets if we can avoid an additional git repo and just
> have it in the ebuild itself it will be the preferred way, since we
> will patch 100s of ebuilds.

[anush, 2010-06-12 00:09:19]

LGTM if its ok with adlr

On 2010/06/11 22:15:16, zbehan wrote:
>

[anush, 2010-06-12 00:11:24]

Btw let djmm know that he can kill the bsdiff.git tree and you should probably
remove them from the DEPS file and manifest.git repo too. 

On 2010/06/12 00:09:19, anush wrote:
> LGTM if its ok with adlr
> 
> On 2010/06/11 22:15:16, zbehan wrote:
> >

[adlr, 2010-06-14 17:03:10]

LGTM