[Fedora-packaging] scl_prefix vs _scl_prefix

[Bohuslav Kabrda]

----- Original Message -----
> 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.html
>   > * 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.
> 

Which is supposed to mean that we can propose it to scl-utils upstream and see what they think about it. I know that scl-utils is very conservative, so adding new macro should be fine, but removing the old one wouldn't be accepted, IMO.

> 
> > > 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?
> 

Is this a test? :)

> 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.
> 

And if you make the typo and use _scl_prefix instead of scl_prefix, you'll end up with a package that doesn't work, I really don't see how removing _scl_prefix would help us.

> 
> -Toshio

-- 
Regards,
Bohuslav "Slavek" Kabrda.