978187 - Update diamond spec file to correspond to reality

Status: RESOLVED FIXED

(Infrastructure & Operations :: RelOps: Puppet, task)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

https://bug968381.bugzilla.mozilla.org/attachment.cgi?id=8383789 contains the build instructions for diamond -- the spec file in the puppet repo won't actually build the right thing.

This should be fixed before the context is forgotten.  In particular the diff between the fork and upstream can be represented as a patch file, and applied during the RPM build process, based on the upstream source.  If the diffs are substantial enough that patching doesn't make sense, then the forked version should be moved to a mozilla github repository (so it's not tied to one person) and the package renamed to mozilla-diamond.

Comment 1

[John Hopkins (:jhopkins)]

Updated src and noarch RPMs uploaded to http://people.mozilla.org/~jhopkins/bug978187/

The noarch.rpm matches the one currently in our releng Yum repo (aside from binary differences).

The src.rpm includes the original source tarball and .diff files against that.  The source tarball was created via 'make sdist' so you may still consider it a special case.

Dustin: I'll wait for your feedback on this.

Comment 2

[Justin Wood (:Callek)]

We want to be able to download a binary (rpm), get its .spec from itself, and then update to a newer source and say "build this" and get a copy.

Having to do special things (like apply diffs from a specific source rpm) to get a suitable rpm is cause for concern.

What should be, imo here. -- the .diff's as .patch files alongside the .spec

The .spec attempt to apply said .patches to the source as it exists (such as if we get a sec release in a week it can work, or if we get a full version in a few months it "should" work assuming no big changes) either way if there are rejects this is cause for someone to need to update the patches, or decide they don't apply to our needs anymore.

In any case the .spec should fail if the patches don't apply, and do the applying for us, even if we don't use the same exact .src.

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

So, in the srpm I see

diamond-3.4.266.tar.gz
diamond.spec
limit-network-collector-stats.diff
version.diff

It looks like limit-network-collector-stats.diff is a legit patch, but I'm confused about version.diff -- why are we telling diamond it's a different version than it really is?  If that's intentional, it definitely deserves a comment!

As for the sdist tarball, ideally the "Source" line would point to an actual download, e.g., https://pypi.python.org/packages/source/d/diamond/diamond-3.4.251.tar.gz.  However, neither 3.4.266 nor 3.4.267 appear to be on pypi, so it's OK to build this one from an sdist.  Can you update the source to point to pypi anyway?  Something like:

# note that pypi does not have every version of diamond; build this from an sdist tarball if necessary
Source0: https://pypi.python.org/packages/source/d/diamond/%{name}-%{unmangled_version}.tar.gz

Once that's set, then as Callek suggested the .spec and .diff files go into the puppetagain repo.

Comment 4

[John Hopkins (:jhopkins)]

Attachment: diamond.spec

Comment 5

[John Hopkins (:jhopkins)]

Attachment: limit-network-collector-stats.diff

Comment 6

[Dustin J. Mitchell [:dustin] (he/him)]

Comment on attachment 8405113 [details]
diamond.spec

Looks good to me - this will produce an RPM with no further complications (assuming the tarball is on pypi)?

Comment 7

[Dustin J. Mitchell [:dustin] (he/him)]

Comment on attachment 8405114 [details] [diff] [review]
limit-network-collector-stats.diff

Can you put the resulting patch up for r? as well?

Comment 8

[John Hopkins (:jhopkins)]

Attachment: [puppet] final patch

Comment 9

[John Hopkins (:jhopkins)]

Comment on attachment 8406132 [details] [diff] [review]
[puppet] final patch

https://hg.mozilla.org/build/puppet/rev/51eecb7599df