Packagers refresher course.

[Texstar]

Just a fresher course to make my job a little easier. Thanks for everything
you guys do. It is very much appreciated!

1. name your spec file with the prefix pclos-name-of-spec.file

2. convert your source tarball to tar.xz
example:

gunzip rkhunter-1.3.6.tar.gz
xz rkhunter-1.3.6.tar

or

bunzip2 rkhunter-1.3.6.tar.bz2
xz rkhunter-1.3.6.tar

This saves us space on ibiblio.org and cuts my upload time way down especially 
on large files. My upload speed is very slow coming off the build server.

3. Please check the Group entry in your spec file and try to match it up with
what is listed in Synaptic under Sections.

4. Please use the %mkrel x macro in the Release part of your specfile. ie
%mkrel 4 or %mkrel 5

4. Please complete the changelog with your info and what you did to the
specfile. This helps me track down if you removed a patch or who to contact if
I have a question.

Example:

%changelog
* Wed Nov 03 2010 Texstar <texstar at gmail.com> 1.3.6-1pclos2010
- new version
- patch1 merged upstream
- comment out patch2 as it does not build with it.

[tele]

Ad. 4
" Is a macro% mkrel that should be used to add MDV after the release, the number can be found Distro Specific Release Tag. "

I don't understand what is macro% 1 , macro% 2 , macro% 4 , why 1 or 2 or 3...  ?
What it is MDV ?

Edit:  

If you are repackaging an app and not upgrading the version but making some other change, please up the release by one number.    

Example:    
%Mkrel     1    
would become ---    
%Mkrel     2    

http://www.pclinuxos.com/forum/index.php/topic,102028.0.html

Edit:
2. Please !
Edit this topic , build in "one" topic  

http://www.pclinuxos.com/forum/index.php/topic,92563.0.html
http://www.pclinuxos.com/forum/index.php/topic,89062.0.html
http://www.pclinuxos.com/forum/index.php/topic,82165.msg946038.html#msg946038

3. I have I have a question on building rpm
 
 a ) How I can build .spec file ?
 b ) From where can I find ?
        BuildRequires:
        Requires:
        Obsoletes:

 c ) Why this is "other"

BuildRequires:   libalsa-devel      >= 1.0.13

BuildRequires:   %{_lib}alsa2-devel      >= 1.0.13

----------------

%{makeinstall}

cd build
%makeinstall_std
cd ..

4. What it is ......_config_pclos , How create it ?

[TerryN]

The %mkrel macro is used to combine the release number with the distro suffix. 
The distro suffix is generated by other macros and for the final RPMS/SRPMS is pclos2012 as in:

firefox-16.0.2-1pclos2012

The release number is incremented for each rebuild of the package with the SAME SOURCE version.  So the first build of firefox 16.0.2 will be done with a %mkrel 1 which will produce:

firefox-16.0.2-1pclos2012

If a change is made to the SPEC file or it has to be rebuilt for some reason then it will be changed to %mkrel 2 which would produce:

firefox-16.0.2-2pclos2012

The increment of the release number ensures that Synaptic sees it as an update even though it is the same version (16.0.2) of firefox.

MDV was the suffix used by Mandriva and should be ignored.
Each packager has their own distro suffix so that when they submit their SRPMs to Neal it is clear who is submitting the package.  For example my suffix is _terryn_ so when I submit SRPMS to Neal they are named like this:

nvidia-current-304.51-1_terryn_2012.src.rpm

Hope that helps,
Terry.

[TerryN]

To answer your other questions (which were added after I posted)

a ) How I can build .spec file ?
 b ) From where can I find ?
        BuildRequires:
        Requires:
        Obsoletes:

I recommend the following documentation:
http://www.montanalinux.org/files/RPM_Build_Manual_Rev2.pdf (a little out-of-date but still useful)
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html
http://www.rpm.org/max-rpm-snapshot/
http://www.pclinuxoshelp.com/index.php/Packaging_for_PCLinuxOS

We recommend that people new to packaging start by updating existing (simple) packages.  This will help you to get familiar with the structure of SPEC files and the various macros and tags used.

c ) Why this is "other"
BuildRequires:   libalsa-devel      >= 1.0.13

BuildRequires:   %{_lib}alsa2-devel      >= 1.0.13

This is done so that the same SPEC file can be used for 64 bit and 32bit.  On 32 bit the library is libalsa2-devel whereas on 64 bit it is lib64alsa2-devel.  The %_lib macro expands to "lib" on 32 bit systems and "lib64" on 64 bit systems.

Terry

[tele]

I use normal pc-linux system , dolphin terminal ( I know about I should use the KDE MiniMe )
"" Error: Found installed (not packaged) files:
    /. directory ""
It is strange, I have this in all folder in the pc-linux ( this is dolphin config files ) ,
  but it is not used in any spec file and I have error.  
thank you again TerryN
I can't find all in montanalinux, fedoraproject and pclinuxoshelp, now I'm reading rpm.org , When I read it, then I will ask further.

Paths , example:
%{_datadir}    this is the same   /usr/share/
http://www.zarb.org/~jasonc/macros.php

[tele]

How works this command?
rpm -qpR kadu-0.12.2-1pclos2012.i586.rpm

This is not from spec file, and this can not find 1 file on system but write all, example

libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)

and so, this is not dependencies from my system, because I have only 1 libc.so.6 , and part of list have similar but not the same name.
This shows only BuildRequires from file in package ?

[TerryN]

This is not from spec file, and this can not find 1 file on system but write all, example

See http://www.pclinuxos.com/forum/index.php/topic,101266.msg905539.html#msg905539

They are dependencies added automatically by rpmbuild.

Terry

[tele]

4. Please use the %mkrel x macro in the Release part of your specfile. ie
%mkrel 4 or %mkrel 5

How use %mkrel is better ?
It seems to me that it does not matter.
1.

Code: [Select]

%define appname                sample
%define ver                    0.8.0.1

Summary:           sample software for modeling and animation.
Name:               %{appname}
Version:             %{ver}
Release:            %mkrel 1
2.

Code: [Select]

%define appname                sample
%define version                    0.8.0.1
%define release                    %mkrel 1

Summary:           sample software for modeling and animation.
Name:               %name
Version:             %version
Release:            %release
%{appname}
This {}  is done so that also the same SPEC file can be used for 64 bit and 32bit ?

[ghostbunny]

hi,

it really doesn't matter where you define the %mkrel x thing.
 

Code: [Select]

%define release %mkrel x
this defines a new variable release with the meaning of the function %mkrel with added x

Code: [Select]

Release: %release set the variable release as content for the Release line.

Code: [Select]

Release: %mkrel x does the same without extra defining the %release variable and if i remember correctly the line

Code: [Select]

Release: xyz defines alsp a variable %release.



the {} are not necessary for the use on 32 and 64 bit, on both arches they have the same meaning and they are only in special situations necessay.

example:

Code: [Select]

Version:             %{ver}

Code: [Select]

Version:             %version
there is no difference between the translations of this macros both %{ver} and %version will be replaced by 0.8.0.1 in your example.

Code: [Select]

Source:  %appnameV-%version

Code: [Select]

Source:  %{appname}V-%version
in the first case you will get an error because %appnameV is not defined and the build system can't find a source with the name -0.8.0.1.

in the second case we concartinate the content of appname with V so we will get sampleV-0.8.0.1

so the {} are primary used when you create new strings where the parts are not seperated by special characters like a dash.

[sling-shot]

So, it would be a better practice to use {} rather than not. Anyway there does not seem to be any downsides to this right ?

Also a good practice would be to name any libraries %{_lib}nameofpakage-etc ?

[TerryN]

Also a good practice would be to name any libraries %{_lib}nameofpakage-etc ?

Library names should be generated by the %mklibname macro as in:

Code: [Select]

%define libname %mklibname %{name}
This will generate the correct architecture specific name for the library.  
If it is a versioned library then use:

Code: [Select]

%define major 1
%define libname %mklibname %{name} %{major}
where major is the library interface version.
Add -d to generate a name for the -devel package if required as in:

Code: [Select]

%define libnamedev %mklibname %{name} %{major} -d
Terry.

[sling-shot]

OK. I need to study this library thing further.
And by the way that Maximum RPM link seems to be a gold mine to be unearthed.

[TerryN]

And by the way that Maximum RPM link seems to be a gold mine to be unearthed.

It is.  Just don't be put off if don't understand it all straight away.  The more you look at this stuff the more it starts to make sense.

Terry.

[tele]

How to compile a 32 bit application on a 64 bit system?
Installing 32-bit chroot?
m32 example: gcc -S -m32 -O2 add.c   is only for gcc
Only in 32 bit system it is possible?

[kjpetrie]

There might be a way, but it's not what we do. We have 32-bit systems for 32-bit compilation, and 64-bit systems for compiling for 64-bit. The .spec file needs to be written to compile on both systems and then the build must be tested on both.

When you submit the SRPM it will be built again using both systems, so it needs to be able to build on both.