On Thu, Dec 6, 2012 at 1:05 PM, Andrew Stitcher <astitc...@redhat.com>wrote:

> On Wed, 2012-12-05 at 17:51 -0500, Rafael Schloming wrote:
> > On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce <dpie...@redhat.com>
> wrote:
> I disagree:

Are you disagreeing with me or Darryl or both? ;-)

There are two scenarios that we care about:
> 1. The install prefix of proton is the same as the install prefix of the
> perl/php/etc.
> In this case everything just works either way round. No problem with
> stripping of the prefix because we just add it back on installation in
> any case. Because this is the case I don't understand at all reason why
> we wouldn't do this for configuration files as well.
> This is the "user" case that Rafi is concerned about.

No actually, the user case I described is where perl and php have
*different* install prefixes, e.g. one is installed in /usr and one is
installed in /usr/local. In this case munging with the install prefix of
proton is guaranteed to do the wrong thing for at least one of php or perl.

2. The specified install prefix is different from the the installed
> prefix of perl/php/etc.
> In this case the reason (for me) of doing "make install" is NOT to try
> to run the just produced modules - obviously without some extra work the
> language environment won't know where to find the extensions. The
> purpose is to get a whole sense of all the artifacts that have been
> produced by the build. If they are spread around the file system it
> becomes difficult to see at a glance whether something you were
> expecting to be there has been left out for instance.
> This case is the "developer" case.

I think you're missing the mixed install root case, of which this is a
subset, and I think this is actually the general case, not purely a
developer use case. If I have system binaries for perl and php, but had to
update ruby to a later build because of some bug fix that hasn't hit the
distro yet, then I might well have perl and php in /usr and ruby in

As far as I can see allowing the developer case to work has no effect on
> whether the "user" case works - since in that case stripping the prefix
> is pretty much a null op since it gets added back anyway.

The best way to cater to the developer scenario you mention is to simply
look at install_manifest.txt. This file is generated whenever you type make
install and will provide a much more accurate check on whether the install
is behaving as it should, and because this is generated automatically by
cmake, it will in pretty much any conceivable scheme as long as we don't
write our own install macro.

> I guess this whole discussion hinges on what you think the outcome of a
> "make install" is. For a simple "user" I agree it should produce
> something that can run and I think that is the case. For a
> developer/package builder I'd say that the point is to produce an image
> of all the artifacts produced by the build.

I don't think we have a conflict here. The semantics I've described provide
users exactly what they want even in the general case mixed install root
scenario, and the install_manifest.txt provides us developers exactly what
we want (and is also very handy for users who want to be able to uninstall).


Reply via email to