Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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_optflags_and_admonitions

Regards
Till
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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_optflags_and_admonitions

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

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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

--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Mention %{_sharedstatedir} difference on RPMMacros for EPEL
 

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