[PATCH 12 of 22] Makefile: replace platform specific rpm build targets with rpm and rpm-py

Matt Mackall mpm at selenic.com
Tue May 20 16:14:54 CDT 2014


On Tue, 2014-05-20 at 20:51 +0200, Mads Kiilerich wrote:
> On 05/20/2014 06:20 PM, Matt Mackall wrote:
> > On Tue, 2014-05-20 at 04:10 +0200, Mads Kiilerich wrote:
> >> # HG changeset patch
> >> # User Mads Kiilerich <madski at unity3d.com>
> >> # Date 1400551681 -7200
> >> #      Tue May 20 04:08:01 2014 +0200
> >> # Node ID 75c1b9ca3644252245840f7276f8223803805a4e
> >> # Parent  b71a9c09bdc9b2a04679a34e0ef0765ffbbbb933
> >> Makefile: replace platform specific rpm build targets with rpm and rpm-py
> > It's quite intentional that there's a "make fedora" target (regardless
> > of how redundant it currently appears). I don't think it's a safe
> > assumption that the package contents and build process for Fedora vs
> > Centos 6 are constant, and we haven't even brought SuSE or any of the
> > other RPM-based distros into the mix.
> 
> I agree that there might be differences in some details. Currently there 
> is no significant differences.

The fact that the two such targets that current exists are nearly
identical is not an accident. It's simply evidence that adding a second
RPM-based target was trivial and adding 'gentoo' or 'windows' targets
was not. RPM-based packages are simply the easiest, least interesting
piece of what I'm trying to do here.

In the bigger picture of all the OSes we might ever want to support
building on, Fedora being able to share build rules with Centos is a
local, possibly temporary quirk and a distraction from the stated goal
of making package building on <OS> be as easy as typing "make <os>".

So there will be "make <os>" targets, end of story. If you want to
factor out some rule commonality, great. I'm also open to tweaking the
names (as there's already obviously some tension with version numbers)
and adding options. You can even add a generic 'rpm' target. But leave
the OS-specific targets in place.

(I'm also not keen on changing the docker-* target names. I don't want
to rule out alternate future (non-Linux? VM-based?) cross-build
solutions, nor do I want to force people building native packages to
have to use Docker.)

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list