Hiyas,
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS and probably also RHEL: https://fedoraproject.org/wiki/Packaging:RPMMacros
Also it would be nice to have the notes about differences in other releases inside a admonition, to make them easier visible.
Regards Till
Till Maas wrote:
Hiyas,
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS and probably also RHEL: https://fedoraproject.org/wiki/Packaging:RPMMacros
Also it would be nice to have the notes about differences in other releases inside a admonition, to make them easier visible.
Regards Till
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Sounds like a great idea for a PackagingDraft. :)
-J
On Tue, Feb 09, 2010 at 07:07:28AM -0600, Jon Ciesla wrote:
Till Maas wrote:
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS and probably also RHEL: https://fedoraproject.org/wiki/Packaging:RPMMacros
Also it would be nice to have the notes about differences in other releases inside a admonition, to make them easier visible.
Sounds like a great idea for a PackagingDraft. :)
I thought it was such a minor change, that it would not require it. Nevertheless, since there were several other issues, I put them together into this draft:
https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optf...
Regards Till
On Wed, Feb 10, 2010 at 12:42:39AM +0100, Till Maas wrote:
On Tue, Feb 09, 2010 at 07:07:28AM -0600, Jon Ciesla wrote:
Till Maas wrote:
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS and probably also RHEL: https://fedoraproject.org/wiki/Packaging:RPMMacros
Also it would be nice to have the notes about differences in other releases inside a admonition, to make them easier visible.
Sounds like a great idea for a PackagingDraft. :)
I thought it was such a minor change, that it would not require it. Nevertheless, since there were several other issues, I put them together into this draft:
https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optf...
Looks good and I think I agree with you that these are just clarifications of language and factual fixes. So no need to vote on them. Thanks for collecting them in one place!
One thing I noticed from reading your draft is that we mention %{_buildrootdir} but don't mention %{buildroot}. The latter is used much more than the former. Should we add this and mention that packagers might be looking for this instead of %{_buildrootdir) anyway?
-Toshio
On Sun, Feb 14, 2010 at 12:16:57AM -0500, Toshio Kuratomi wrote:
One thing I noticed from reading your draft is that we mention %{_buildrootdir} but don't mention %{buildroot}. The latter is used much more than the former. Should we add this and mention that packagers might be looking for this instead of %{_buildrootdir) anyway?
%{buildroot} probably fits best in the "Other macros" section, because it is a macro to be used inside the spec. Bug the %{_buildrootdir} macros like the other RPM directory macros is afaik supposed to be used only with rpmbuild --define to change the behaviour of rpmbuild.
I have updated the draft to address this, but now it is getting ugly to only merge some changes.
I also changed some other issues and mentioned two, that I did not yet address: %{optflags} does not match the real expanded value and it is imho bad to have two macros for the same path, e.g. %{_usr} and %{_prefix}.
Regards Till
2010/2/14 Till Maas opensource@till.name wrote:
%{buildroot} probably fits best in the "Other macros" section, because it is a macro to be used inside the spec. Bug the %{_buildrootdir} macros like the other RPM directory macros is afaik supposed to be used only with rpmbuild --define to change the behaviour of rpmbuild.
Was typing the nonexistent %{_buildroot} instead of %{buildroot} a typo?
On a somewhat related note, some directory macros (e.g., %_keyringpath) contain trailing slashes, while others don't. Does this matter enough to be worth addressing?
On Mon, Feb 15, 2010 at 06:58:42PM -0600, Garrett Holmstrom wrote:
2010/2/14 Till Maas opensource@till.name wrote:
%{buildroot} probably fits best in the "Other macros" section, because it is a macro to be used inside the spec. Bug the %{_buildrootdir} macros like the other RPM directory macros is afaik supposed to be used only with rpmbuild --define to change the behaviour of rpmbuild.
Was typing the nonexistent %{_buildroot} instead of %{buildroot} a typo?
Yes, I just fixed this.
On a somewhat related note, some directory macros (e.g., %_keyringpath) contain trailing slashes, while others don't. Does this matter enough to be worth addressing?
%_keyringpath is not mentioned at all and according to 'rpm --showrc | %grep "/$"' it is the only macro with a trailing slash. So maybe this can just be changed. But it also does not hurt that much, because afaik a double slash in a path will be handled like a single slash.
Regards Till
On Wed, 17 Feb 2010, Till Maas wrote:
On Mon, Feb 15, 2010 at 06:58:42PM -0600, Garrett Holmstrom wrote:
2010/2/14 Till Maas opensource@till.name wrote:
%{buildroot} probably fits best in the "Other macros" section, because it is a macro to be used inside the spec. Bug the %{_buildrootdir} macros like the other RPM directory macros is afaik supposed to be used only with rpmbuild --define to change the behaviour of rpmbuild.
Was typing the nonexistent %{_buildroot} instead of %{buildroot} a typo?
Yes, I just fixed this.
On a somewhat related note, some directory macros (e.g., %_keyringpath) contain trailing slashes, while others don't. Does this matter enough to be worth addressing?
%_keyringpath is not mentioned at all and according to 'rpm --showrc | %grep "/$"' it is the only macro with a trailing slash. So maybe this can just be changed. But it also does not hurt that much, because afaik a double slash in a path will be handled like a single slash.
%_keyringpath is nothing packagers should be concerned with. Neither is %_buildrootdir. These are rpm internals, unfortunately the macro namespace is well and thoroughly mixed up wrt what "internal" and whats not.
- Panu -
On Thu, 18 Feb 2010 22:26:12 +0200 (EET) Panu Matilainen pmatilai@laiskiainen.org wrote:
On Wed, 17 Feb 2010, Till Maas wrote:
On Mon, Feb 15, 2010 at 06:58:42PM -0600, Garrett Holmstrom wrote:
2010/2/14 Till Maas opensource@till.name wrote:
%{buildroot} probably fits best in the "Other macros" section, because it is a macro to be used inside the spec. Bug the %{_buildrootdir} macros like the other RPM directory macros is afaik supposed to be used only with rpmbuild --define to change the behaviour of rpmbuild.
Was typing the nonexistent %{_buildroot} instead of %{buildroot} a typo?
Yes, I just fixed this.
On a somewhat related note, some directory macros (e.g., %_keyringpath) contain trailing slashes, while others don't. Does this matter enough to be worth addressing?
%_keyringpath is not mentioned at all and according to 'rpm --showrc | %grep "/$"' it is the only macro with a trailing slash. So maybe this can just be changed. But it also does not hurt that much, because afaik a double slash in a path will be handled like a single slash.
%_keyringpath is nothing packagers should be concerned with. Neither is %_buildrootdir. These are rpm internals, unfortunately the macro namespace is well and thoroughly mixed up wrt what "internal" and whats not.
Another couple of macros that are occasionally useful in specs are %{_builddir} and %{buildsubdir} - could they be added too?
Paul.
On Wed, Feb 10, 2010 at 12:42:39AM +0100, Till Maas wrote:
On Tue, Feb 09, 2010 at 07:07:28AM -0600, Jon Ciesla wrote:
Till Maas wrote:
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS and probably also RHEL: https://fedoraproject.org/wiki/Packaging:RPMMacros
Also it would be nice to have the notes about differences in other releases inside a admonition, to make them easier visible.
Sounds like a great idea for a PackagingDraft. :)
I thought it was such a minor change, that it would not require it. Nevertheless, since there were several other issues, I put them together into this draft:
https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optf...
This proposal is now quite old (about 7 weeks), when will it be accepted or rejected?
Regards Till
Till Maas wrote:
On Wed, Feb 10, 2010 at 12:42:39AM +0100, Till Maas wrote:
On Tue, Feb 09, 2010 at 07:07:28AM -0600, Jon Ciesla wrote:
Till Maas wrote:
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS and probably also RHEL: https://fedoraproject.org/wiki/Packaging:RPMMacros
Also it would be nice to have the notes about differences in other releases inside a admonition, to make them easier visible.
Sounds like a great idea for a PackagingDraft. :)
I thought it was such a minor change, that it would not require it. Nevertheless, since there were several other issues, I put them together into this draft:
https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optf...
This proposal is now quite old (about 7 weeks), when will it be accepted or rejected?
Regards Till
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Presumptively at the next FPC meeting. I'm not sure when the next one is scheduled.
-J
On Wed, Mar 31, 2010 at 07:18:06AM -0500, Jon Ciesla wrote:
Till Maas wrote:
This proposal is now quite old (about 7 weeks), when will it be accepted or rejected?
Presumptively at the next FPC meeting. I'm not sure when the next one is scheduled.
According to the FPC wiki page[0], meetings are every other Wednesday, so several meetings have already passed, why would the next one be different?
Regards Till
[0] https://fedoraproject.org/wiki/Packaging:Committee#Meetings
Till Maas wrote:
On Wed, Mar 31, 2010 at 07:18:06AM -0500, Jon Ciesla wrote:
Till Maas wrote:
This proposal is now quite old (about 7 weeks), when will it be accepted or rejected?
Presumptively at the next FPC meeting. I'm not sure when the next one is scheduled.
According to the FPC wiki page[0], meetings are every other Wednesday, so several meetings have already passed, why would the next one be different?
Regards Till
[0] https://fedoraproject.org/wiki/Packaging:Committee#Meetings
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
They haven't been occurring quite as regularly as that.
-J
On 02/09/2010 12:58 PM, Till Maas wrote:
Hiyas,
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS
This would be "simply plain wrong".
The GNU Standards define it as:
sharedstatedir' The directory for installing architecture-independent data files which the programs modify while they run.
On Fedora it evaluates to /var/lib, which is a meaningful setting.
%{_prefix}/com matches to the default the GNU Standards describe, but in a distro's constext, this would seem to be "simply plain wrong" to me == I consider the setting on CentOS to be a bug.
Ralf
On Tue, Feb 09, 2010 at 02:20:44PM +0100, Ralf Corsepius wrote:
On 02/09/2010 12:58 PM, Till Maas wrote:
Hiyas,
I noticed that the RPMMacros page does not mention that %{_sharestatedir} expands to %{_prefix}/com on CentOS
This would be "simply plain wrong".
The GNU Standards define it as:
sharedstatedir' The directory for installing architecture-independent data files which the programs modify while they run.
On Fedora it evaluates to /var/lib, which is a meaningful setting.
%{_prefix}/com matches to the default the GNU Standards describe, but in a distro's constext, this would seem to be "simply plain wrong" to me == I consider the setting on CentOS to be a bug.
It is, but it's not something that's going to change within the release. We need to ducment the difference so people porting a Fedora package to EPEL-5 know not to rely on %{_sharestatedir} there.
-Toshio
It is, but it's not something that's going to change within the release. We need to ducment the difference so people porting a Fedora package to EPEL-5 know not to rely on %{_sharestatedir} there.
-Toshio
yes, I see that some day's ago.
packaging@lists.fedoraproject.org
-
Garrett Holmstrom -
itamar -
Jon Ciesla -
Panu Matilainen -
Paul Howarth -
Ralf Corsepius -
Till Maas -
Toshio Kuratomi