Request for a sponsor and a review of: pam_abl

Oliver Falk oliver at linux-kernel.at
Wed Jul 13 14:33:03 UTC 2005


On 07/13/2005 04:18 PM, Alexander Dalloz wrote:
> Am Mi, den 13.07.2005 schrieb Michael Schwendt um 14:31:
[ ...]
>>>>Specfile:
>>>>* Release should be 1%{?dist}
>>>
>>>Ok, so the dist tag seems to be mandatory, other than the wiki says.
>>
>>No, it isn't.
> 
> Hm, for 2 rpms without dist tag set I got for both the feedback to set
> it. I thought at least for the keychain rpm, which just puts the shell
> script and man page into rpm the dist tag does not make much sense. For
> packages build against specific distribution version libs I think it
> makes sense to have an "indicator" like the dist tag in the package
> filename.

It's main purpose, yes, is to indicate for which distribution the 
package is meant for and even for rpms which just install shell-scripts 
and manpages, it's good to know, that the package *is meant for 
distribution X*, since if I would be some dummy user, I can - more or 
less - believe, that the package *will work* on this distribution. :-)

> A different question, but too regarding package naming. The pam_abl
> source code tarball is named by it's author
> 
> pam_abl-20050110-0.2.2.tar.gz
> 
> I initially thought it would be proper to set
> 
> %{name} -> pam_abl
> %{version} -> 0.2.2
> %{release} -> 20050110
> 
> Using the dist tag means that wherever %{release} should be used I
> instead have to use "20050110", like in Source0 or BuildRoot. I am on
> the right path?
> Another issue with the %{release} is the way how to increase it for
> reflecting rpm changes. What would be the proper choice for %{release}?
> 
> %{release} -> 20050110-1%{?dist}
> 
> In this way? Or better to omit the date value and using a self chosen
> release number? What's the recommended way?

If the date isn't really part of the real version, omit it. If the date 
would be the version, because the guy does release a new version every 
day (who the hell does this?), it would be ok, to use the date as 
version - I think. So use *you* rpm release for the release tag...

>>>>E: pam_abl hardcoded-library-path in /lib/security/$ISA/pam_abl.so
>>>
>>>Where is that error triggered from?
>>
>>rpmlint examining your PAM file.
> 
> So, like Oliver guesses, I think it must be triggered by the path
> mentioned in the %description section.

Hope so. :-)

>>On x86_64, PAM modules are stored in /lib64/security/..., so it is
>>a mistake to hardcode the path. Just put "pam_abl.so" there.
>  
> I think I took care for this.

AFAIK, you did.

Best,
  Oliver




More information about the fedora-extras-list mailing list