Here's a relatively [ ;-) ] non-controversial change needed to the draft. Right now we have both _scl_prefix and scl_prefix macros. We need to rename one of those. Names that differ only in punctuation are confusing. It looks like _scl_prefix is used less in the draft. So that's probably the candidate to rename. Perhaps something like %{_scldir} to be similar to %{_libdir}, %{_sysconfdir}, etc?
-Toshio
On 11/04/2013 05:31 PM, Toshio Kuratomi wrote:
Here's a relatively [ ;-) ] non-controversial change needed to the draft. Right now we have both _scl_prefix and scl_prefix macros. We need to rename one of those. Names that differ only in punctuation are confusing. It looks like _scl_prefix is used less in the draft. So that's probably the candidate to rename. Perhaps something like %{_scldir} to be similar to %{_libdir}, %{_sysconfdir}, etc?
-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
That's upstream decision. I'm not sure if it doesn't break backward compatibility. CC'ing the upstream.
Marcela
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:
Here's a relatively [ ;-) ] non-controversial change needed to the draft. Right now we have both _scl_prefix and scl_prefix macros. We need to rename one of those. Names that differ only in punctuation are confusing. It looks like _scl_prefix is used less in the draft. So that's probably the candidate to rename. Perhaps something like %{_scldir} to be similar to %{_libdir}, %{_sysconfdir}, etc?
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.
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.
-Toshio
----- 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.
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 :)).
-Toshio
Slavek
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.ht...
- 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
----- 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.ht...
- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 04/11/2013 17:31, Toshio Kuratomi a écrit :
Here's a relatively [ ;-) ] non-controversial change needed to the draft. Right now we have both _scl_prefix and scl_prefix macros. We need to rename one of those. Names that differ only in punctuation are confusing. It looks like _scl_prefix is used less in the draft. So that's probably the candidate to rename. Perhaps something like %{_scldir} to be similar to %{_libdir}, %{_sysconfdir}, etc?
I agree scl_prefix and _scl_prefix confusing (even if looking in all my spec files, I only found 1 use of _scl_prefix, and for a tricky reason).
Despite, we also need to make explicitly where its value come from.
Currently it come from scl-utils-build and defined as /opt/rh
I really think it should be defined in scl-foo-build and inherited for all the packages of the collection.
Explanation: if I want to build extension for different collections from different vendor, I can't rely on default value.
When building another depedent SCL, I also need to know 2 prefix (prefix for my collection, and prefix for the used collection).
When building a SCL package using another collection, I will have installed (BR) -build for my collection and only -runtime for the used collection.
So in scl-foo-runtime => %_foo_scl_prefix in scl-foo-build => %_scl_prefix
Notice: this is already used for other macros in python27-runtime => %_python27_python in python27-build => %_python
Then, this is for a single tree.
If we choose to split the tree in /etc, /var/, /usr, ... we also need a new set of macro for each dir.
Instead of relying on %{_scl_root}%{_root_sysconfigdir}
in scl-foo-runtime => %_foo_sysconfigdir in scl-foo-build => %_sysconfigdir
So a dependent collection will be able to known where are stored system config files %_root_sysconfigdir collection config files %_sysconfigdir dependent scl config files %_foo_sysconfigdir
Yes, this is really a nightmare.
So my final thoughts (trying to be pragmatic)
- - we should use a single self contained tree
- - we should use /opt
- - we should use /opt/rh
I don't know what RH means, perhaps "Rush Hours", "Rich Hive", "Really Happy", "Relocated Home" or something else.
Sorry to be very pessimist, but using any other value, will just make all the things much more complex, and probably unusable.
The upstream SCL project have made some choices. Those are perhaps not the best, and we can discuss during hours, I think we very probably never get somewhere. So, just follow upstream.
Regards, Remi.
P.S. If I want to sell cars, I can dislike the wheel position, and discuss it should be left or right, even for good reason, I can't change it easily.
----- Original Message -----
-----BEGIN PGP SIGNED MESSAGE----- I really think it should be defined in scl-foo-build and inherited for all the packages of the collection.
Explanation: if I want to build extension for different collections from different vendor, I can't rely on default value.
When building another depedent SCL, I also need to know 2 prefix (prefix for my collection, and prefix for the used collection).
When building a SCL package using another collection, I will have installed (BR) -build for my collection and only -runtime for the used collection.
So in scl-foo-runtime => %_foo_scl_prefix in scl-foo-build => %_scl_prefix
Having macros in the -runtime package? Please don't. - You always have %_scl_prefix (or whatever will that be named) in your -build. - If you need prefix of the collection that you depend on by %global %_collection_i_depend_on_scl_prefix `cat /etc/scl/prefixes/collection_i_depend_on`
You can define that in your -build subpackage if you need to use that often.
Instead of relying on %{_scl_root}%{_root_sysconfigdir}
in scl-foo-runtime => %_foo_sysconfigdir in scl-foo-build => %_sysconfigdir
So a dependent collection will be able to known where are stored system config files %_root_sysconfigdir collection config files %_sysconfigdir dependent scl config files %_foo_sysconfigdir
Yes, this is really a nightmare.
I guess this makes sense and it would be possible to implement this into scl-utils, so that build of metapackage would produce a file containing these macros. The only question is where to place them - the -build is no-go, since that can't be installed when building depending collections.
So my final thoughts (trying to be pragmatic)
- we should use a single self contained tree
- we should use /opt
- we should use /opt/rh
I don't think so. We should rather get LANANA name for Fedora and use that.
Regards, Remi.
Slavek.
Le 06/11/2013 10:04, Bohuslav Kabrda a écrit :
- we should use /opt/rh
I don't think so. We should rather get LANANA name for Fedora and use that.
OK. Go with LANANA name.
So please add in the Draft.
"All the package in a collection must use the same vendor. Package cannot extends collection of other vendor."
Remi.
P.S yes this explicitly excludes extension of RHSCL in EPEL.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 06/11/2013 07:32, Remi Collet a écrit :
When building a SCL package using another collection, I will have installed (BR) -build for my collection and only -runtime for the used collection.
So in scl-foo-runtime => %_foo_scl_prefix in scl-foo-build => %_scl_prefix
Sorry, I mean _root_prefix here.
%_scl_prefix = /opt/rh (for exemple) directory own by scl-utils macro defined by scl-utils
This is consistent
%_root_prefix = /opt/rh/foo/root directory own by foo-untime macro defined by scl-utils (as %_scl_prefix/%sclname/root)
This is obviously not consistent
Remi.
----- Original Message -----
%_root_prefix = /opt/rh/foo/root directory own by foo-untime macro defined by scl-utils (as %_scl_prefix/%sclname/root)
%_datadir = /usr/share directory owned by filesystem macro defined by rpm
Is this inconsistent too?
This is obviously not consistent
Remi.
Le 08/11/2013 08:05, Bohuslav Kabrda a écrit :
----- Original Message -----
%_root_prefix = /opt/rh/foo/root directory own by foo-untime macro defined by scl-utils (as %_scl_prefix/%sclname/root)
%_datadir = /usr/share directory owned by filesystem macro defined by rpm
Is this inconsistent too?
You cannot compare.
SCL are very different because of vendor.
When scl-utils vendor is not the package vendor this inconsitency create an issue.
Remi.
This is obviously not consistent
Remi.
----- Original Message -----
Le 08/11/2013 08:05, Bohuslav Kabrda a écrit :
----- Original Message -----
%_root_prefix = /opt/rh/foo/root directory own by foo-untime macro defined by scl-utils (as %_scl_prefix/%sclname/root)
%_datadir = /usr/share directory owned by filesystem macro defined by rpm
Is this inconsistent too?
You cannot compare.
Sure I can. The relationship filesystem<->rpm is the same as foo-runtime<->scl-utils
SCL are very different because of vendor.
When scl-utils vendor is not the package vendor this inconsitency create an issue.
That is solved by redefining _scl_prefix in your own metapackage. I really don't see the problem.
Remi.
This is obviously not consistent
Remi.
Le 08/11/2013 08:33, Bohuslav Kabrda a écrit :
When scl-utils vendor is not the package vendor this inconsitency create an issue.
That is solved by redefining _scl_prefix in your own metapackage. I really don't see the problem.
This is exactly the problem = > you don't see the problem.
You cannot redefine _scl_prefix in each package. - this will be redundant and tricky - you don't know which is the correct directory (owned by foo-runtime)
Definitively, I think I must forgive the idea of extending RHSCL in EPEL.
If RHSCL users want to extends existing SCL, they will have to rely on themselves or Red Hat?
Remi.
----- Original Message -----
Le 08/11/2013 08:33, Bohuslav Kabrda a écrit :
When scl-utils vendor is not the package vendor this inconsitency create an issue.
That is solved by redefining _scl_prefix in your own metapackage. I really don't see the problem.
This is exactly the problem = > you don't see the problem.
You cannot redefine _scl_prefix in each package.
That is "by design". It you want another _scl_prefix, you should build another collection that depends on collection you want to use.
- this will be redundant and tricky
- you don't know which is the correct directory (owned by foo-runtime)
Definitively, I think I must forgive the idea of extending RHSCL in EPEL.
Extending as in "building more packages into the same collection"? You shouldn't be able to do that, that is by desing of RHSCL afaik. Extending as in "building my own collection that depends on collection from RHSCL"? You will be able to do that.
If RHSCL users want to extends existing SCL, they will have to rely on themselves or Red Hat?
So if the only problem is that you cannot redefine _scl_prefix in every package, then I guess there is not problem, because scl-utils are meant to work this way.
Remi.
Le 08/11/2013 08:58, Bohuslav Kabrda a écrit :
Extending as in "building more packages into the same collection"? You shouldn't be able to do that, that is by desing of RHSCL afaik.
Yes, this is my first thought.
Toshio, can you please update the Guildelines draft about this ?
"All SCL packages MUST be part of en existing collection in Fedora/EPEL (cannot extend a collection from another vendor, such as RHSCL or RHDTS)"
Remi.
packaging@lists.fedoraproject.org
-
Bohuslav Kabrda -
Marcela Mašláňová -
Remi Collet -
Toshio Kuratomi