[Scons-users] tagging files (RPM packaging)

[Mats Wichmann]

On 1/1/22 07:16, Werner Reisberger wrote:
> The RPM packages I am trying to build with SCons require certain tags
> but most of the tags does not work out of the box.
> 
> E.g. The SCons man page proposes the following call to tag a file with
> the DOC attribute:
> 
>     # marks file2.txt to be a documentation file
>     Tag('file2.txt', DOC)
> 
> This does not work. I have to say
> 
>     Tag('file2.txt', DOC=' ')
> 
> That's because the tag is defined as
> 
>     'PACKAGING_DOC'              : '%%doc %s',
> 
> but DOC attributes in RPM spec files have the format
> 
>      %doc file_name
> 
> It's different with the UNIX_ATTR tag where file mode and owner/group
> have to be appended like
> 
>      %attr(644, root, adm) /etc/yp.conf
> 
> The tag command for UNIX_ATTR in the SCons man page also doesn't work:
> 
>      # makes sure the built library will be installed with 644 file
> access mode
>      Tag(Library('lib.c'), UNIX_ATTR="0o644")
> 
> You need to follow the RPM specification
> (http://ftp.rpm.org/max-rpm/s1-rpm-anywhere-specifying-file-attributes.html)
> 
> 
> However the tagging test script on GitHub does it right.
> 
> Like the DOC attribute the following tag definitions need to be fixed:
> 
>         'PACKAGING_CONFIG'           : '%%config %s',            # =>
> '%%config'
>         'PACKAGING_CONFIG_NOREPLACE' : '%%config(noreplace) %s', # =>
> '%%config(noreplace)'
>         'PACKAGING_UNIX_ATTR'        : '%%attr %s',              # =>
> '%%attr(%s)'
>         'PACKAGING_LANG_'            : '%%lang(%s) %s',          # =>
> '%%lang(%s)'
>         'PACKAGING_X_RPM_VERIFY'     : '%%verify %s',            # =>
> '%%verify (%s)' ?
>         'PACKAGING_X_RPM_DIR'        : '%%dir %s',               # =>
> '%%dir'
>         'PACKAGING_X_RPM_DOCDIR'     : '%%docdir %s',            # =>
> '%%docdir'
>         'PACKAGING_X_RPM_GHOST'      : '%%ghost %s', }           # =>
> '%%ghost'
> 
> Unfortunately my python knowledge is rather basic but let me know how I
> can help.

Looks like this code hasn't been touched in a very long time (except for
some fiddling of docstrings and newer Python syntax, it's largely
unchanged since 2007) .  One wonders if it's actually being used - you
may be a trailblazer here! Not sure if the actual problem is the tag
specifications or the tag "compiler" in the code, we should be able to
figure it out though.  Help could be as simple as providing a minimal
SConscript that shows the problem.

> 
> Happy 2022 and keep on going with your great work!
> 

Thanks!