One point questions only

[sling-shot]

What is the difference between name and base_name in a .spec file?

Ref - .spec file from PCLinuxOS Live USB Creator :

Code: [Select]

%define        base_name PCLinuxOS LiveUSB Creator
%define        name      PCLinuxOS-liveusb


[ghostbunny]

This both lines define a new variable. They don't have any special meaning. They just contain the different strings.

i didn't look in the spec but i think name is used for the source and package name and the whole things which have to do with file and folder paths' while base_name is probably used for creating the name in the desktop file entry. Can't imagine anything else because names with space in it are very untypical.

you could name name also blablub than you just have to replace the %{name} and %name thing in the spec by %{blablub} or %blablub

[sling-shot]

There is no reference to base_name anywhere else in the .spec file.

[daniel]

Yes you are right...
But in the past there was an reference, long time ago.
You can move it, if you like 

[sling-shot]

2. Original package name includes a mixture of capital and small letters. However Linux convention seems to be all small letters. If I want to convert this I will have to change the executable name, directory name etc. Do not know if it will break anything.
What to do in such a situation?
Is there a method of creating a shortcut / symlink or whatever connecting to the original software but this link will be in small letters?

(This has arisen from trying to package QtWeb binary. Here the name and the tarball name are in mixed case.)

[ghostbunny]

if i remember correctly you created a extra launcher in /usr/bin for qtweb. it is enough to give this launcher file a name which just contains lower case letters. there is no need to change whole directory structures.

in the case of the source you can define new macro like

Code: [Select]

%define sname QtWebwhich results in a Source line like

Code: [Select]

Source: %sname-%version

but also just

Code: [Select]

Source: QtWeb-%version

is possible.

[sling-shot]

if i remember correctly you created a extra launcher in /usr/bin for qtweb.

I had only created a .desktop file. No launcher in /usr/bin

How about creating a bash script named qtweb but containing only

Code: [Select]

#!/bin/bash
QtWeb

using

Code: [Select]

%__cat > %{buildroot}%{_bindir}/qtweb << EOF
#!/bin/bash
QtWeb
EOF

But, how to set execute permission for this generated script?

[ghostbunny]

if i remember correctly you created a extra launcher in /usr/bin for qtweb.

I had only created a .desktop file. No launcher in /usr/bin

How about creating a bash script named qtweb but containing only

Code: [Select]

#!/bin/bash
QtWeb

using

Code: [Select]

%__cat > %{buildroot}%{_bindir}/qtweb << EOF
#!/bin/bash
QtWeb
EOF

But, how to set execute permission for this generated script?

creating a script is also possible. to set execution permission set chmod +x <filename> in your case

Code: [Select]

%__cat > %{buildroot}%{_bindir}/qtweb << EOF
#!/bin/bash
QtWeb
EOF

chmod +x %{buildroot}%{_bindir}/qtweb


[sling-shot]

That worked great. Thanks.

[sling-shot]

3. When considering BuildRequires and Requires, should I add dependencies as needed for non-KDE desktops too?

Suppose I am building a Qt package, KDE desktop may already have the libraries needed while a non-KDE may not.
Particularly in the case of QtWeb, it builds and installs cleanly in KDE desktops with BuildRequires: libqt4-devel alone and no Requires: seem to be needed. But today I just installed LXDE in VirtualBox and tried installing the resulting .rpm. libQtNetwork.so.4 and libQtWebKit.so.4 dependencies were unmet and package was uninstallable.

[TerryN]

But today I just installed LXDE in VirtualBox and tried installing the resulting .rpm. libQtNetwork.so.4 and libQtWebKit.so.4 dependencies were unmet and package was uninstallable.

I'm guessing you are trying to install it using rpm command? (I do wish you 'd give us details rather than tell a story  )
That won't work because you have nothing to resolve the dependencies for you.  That's why we have "package managers" like apt and synaptic  

Terry.

[sling-shot]

3. When considering BuildRequires and Requires, should I add dependencies as needed for non-KDE desktops too?

Unfortunately trying to explain my question landed me in this soup I will post that latter part to my QtWeb thread. I had actually used "apt-get install xxx.rpm" there.

So back to topic, is there a simple answer to Q. 3?

[TerryN]

3. When considering BuildRequires and Requires, should I add dependencies as needed for non-KDE desktops too?

"BuildRequires" is there to help others (especially Neal) build your packages successfully.  It's best to make no assumptions about other people's build systems and include all the capabilities needed to build the package successfully.  Most packagers can cope with missing buildreqs but you won't make many friends if it causes a 4 hour build to fail after 3 hours and 59 minutes 

I've said before that "Requires" are only necessary for packages which are not catered for by RPM's automatic dependency facility (mainly scripted languages like python, perl, shell etc.) or to specify an indirect requirement.  An indirect requirement is a dependency that is needed to make an app "useful" rather than necessary to install and run it.

Terry.

[sling-shot]

I can only know by doing a full packaging setup, then running gbd and check if that .rpm is ok in that environment.
Well...

[TerryN]

I can only know by doing a full packaging setup, then running gbd and check if that .rpm is ok in that environment.

Yes, you certainly should be testing that your RPM installs from a proper repo setup using Synaptic.  That's how end-user will be trying to install it 

Terry.