Re: [Fedora-packaging] scl_prefix vs _scl_prefix

[Toshio Kuratomi]

On Wed, Nov 06, 2013 at 02:26:30AM -0500, Bohuslav Kabrda wrote:
>  ----- Original Message -----
>  > On Tue, Nov 05, 2013 at 01:27:41PM +0100, Marcela Mašláňová wrote:
>  > > On 11/04/2013 05:31 PM, Toshio Kuratomi wrote:
>  > > That's upstream decision. I'm not sure if it doesn't break
> backward
>  > > compatibility. CC'ing the upstream.
>  > > 
>  > slavek said that we could change things like this so I bring it up.
>  > 
>  
>  Did I? I think I might have said that we can add a macro that will be named differently
> and have the same value, but I don't think that I've ever said that we can throw
> any of current macros away.
>   

https://lists.fedoraproject.org/pipermail/packaging/2013-September/009535...
>  * Can we assume that the implementation can be changed to address
>  problems, add features, or follow different conventions?  Can be done
>  if backwards compat is possible?  Or is implementation set in stone so
>  we'd have to kludge around any shortcomings?
>   
  So, this is a very general question, so my answer is: Depends. If we come up with a sane
proposal, I think the scl-utils upstream will accept, but I can't really say that in
general.


>  > If backwards compatibility is important, you can define both
> _scl_prefix and
>  > _scldir to the same meanings and document that _scl_prefix is deprecated.
>  > However, that's not ideal as it doesn't prevent people from using
>  > %{_scl_prefix} when they meant to use %{scl_prefix} and getting confused.
>  > If %{_scl_prefix} is undefined, then rpmbuild would throw an error instead
>  > 
>  > In the draft itself, %{_scl_prefix} isn't used in any public place so it may
>  > not have large backwards compatibility problems, though.
>  > 
>  
>  I'd prefer leaving it. If we don't talk about _scl_prefix, I guess that people
> won't run into this problem. (It doesn't seem likely to try to write scl_prefix
> and put an underscore before that as a typo :)).
>   
I'd very much prefer changing it.  Without testing, which of these is
correct?

_prefix or prefix?
_libdir or libdir?
_perl_sitelib or perl_sitelib?
_python_sitelib or python_sitelib?
_pear_datadir or pear_datadir?
_builddir or builddir?
_buildrootdir or buildrootdir?
_buildroot or buildroot?
_javadocdir or javadocdir?

When looking at a spec file that you haven't written (because you took over
maintainance from someone else, you are a provenpackager, or you are
reviewing someone else's package) you may not see any which of these things
are wrong.  With the above, you'll at least see that there's an unexpanded
macro in your build.log.  If both were defined you wouldn't even have that.


-Toshio