----- 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. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
