Re: Bug with pkg if only a single file is installed

[David Bateman]

Søren Hauberg wrote:
> Wow, this is great news. Now we need .deb and windows support. I don't
> know anything about either these, but I assume .deb is fairly similar
> to .rpm. For windows I guess we could build packages and ship them as
> Octave packages. We could also just ignore the Windows platform when it
> comes to binary packages.

I've dealt very little with deb packaging and so, would rather leave
that to someone else. In fact I can't really be called an expert of rpm
packaging either. I see what I'm doing as a first start that someone
like Quentin for the RPMs and the debian octave team for the debs might
use as some sort of guidance on how to package.

Its also allowing me to identify the problems with pkg.m before it
starts to really be used by too many people so that we can avoid some
bug reports later on, and perhaps the need for backwards incompatiable
changes to the packages needed by the package manager.

> 
>> Thinking about the issue of external dependencies, there is a problem
>> with the DESCRIPTION files as they stand. Basically I want to use the
>> SystemRequirements: field of the DESCRIPTIONS file to automatically
>> generate the external build dependencies for the package. The problem is
>> that the package names for certain functionality is not uniform across
>> distributions. For example libtermcap on fedora seems to be libtermcap2
>> on mandriva, etc. Therefore it seems to me that the SystemRequirements:
>> field of DESCRIPTIONS is not enough.
>>
>> I see two choices. We could replace the SystemRequirements field with
>> multiple fields with names like "Fedora:", "Mandriva:", "Debian:", etc.
>> Alternatively we might modify the dependencies in SystemRequirements: to
>> be something like
>>
>> SystemRequirements: [Fedora]libtermcap (> 2.0.6), [Mandriva]libtermcap2
>> (> 2.0.6)
>>
>> to allow distribution specific requirements. Furthermore, we might have
>> different build and install dependencies and how to we treat these with
>> the current scheme. Any thought on how to address this?
> I've been thinking about the issue for a long time (I haven't really
> found a good solution). SystemRequirements is basicly there to help
> automatic creation of .rpm and .deb files. Another solution than the
> ones you suggested would be to have 
> 
> FedoraSystemRequirements: libtermcap (> 2.0.6)
> MandrivaSystemRequirements: libtermcap2 (> 2.0.6)
> 
> I guess that would be more easy to parse. Then the SystemRequirements
> field would be for all other distributions than those that have
> specialized fields.
> 
> pkg.m doesn't really care which fields are in the DESCRIPTION file, so
> the above solution doesn't require any changes to pkg.m. The same is
> also true for the other solutions since the SystemRequirements field
> isn't handled by pkg.m.
> 
> So, I have thoughts, but I don't have great thoughts :-)

And what about the difference between "BuildRequires:" and "Requires:"
options in RPM spec-files? I suppose Debian have similar options. Maybe
the easiest solution is in fact something like

Mandriva: Requires: ImageMagick (> 6.2.0)
Mandriva: BuildRequires: ImageMagick-devel (> 6.2.0)
Mandriva: Requires: libtermcap2 (> 2.0.6)

This makes installing the right code in the RPM spec-file and debian
rules file just a matter of stripping the keywords. In fact I think
maybe something like

Suse Redhat: libtermcap (> 2.0.6)
Mandriva Mandrake: libtermcap2 (> 2.0.6)
RPM: Requires: ImageMagick (> 6.2.0)
RPM: BuildRequires: ImageMagick-devel (> 6.2.0)

should be allowed, so that the DESCRIPTION files don't get too long.
Then the only question is how to probe the distribution. Unfortunately,
although it looks like uname will be modified to give the distribution
in the future it doesn't at the moment and so we have to you an indirect
technique, something like

if [ -e "/etc/mandriva-release" ]; then
  DIST=Mandriva
elif [ -e "/etc/mandrake-release" ]; then
  DIST=Mandrake
elif [ -e "/etc/fedora-release" ]; then
  DIST=Fedora
elif [ -e "/etc/redhat-release" || -e "/etc/redhat_version" ]; then
  DIST=Redhat
elif [ -e "/etc/SuSE-release" ]; then
  DIST=Suse
elif [ -e "/etc/debian_version" || -e "/etc/debian_release"]; then
  DIST=Debian
elif [ -e "/etc/ubuntu-release" ];
  DIST=Ubuntu
elif [ -e "/etc/slackware-release" || -e "/etc/slackware_version" ]; then
  DIST=Slackware
elif [ -e "/etc/yellowdog-release" ]; then
  DIST=Yellowdog
elif [ -e "/etc/gentoo-release" ]; then
  DIST=Gentoo
elif [ `uname | grep -i mingw` ]; then
  DIST=Mingw
elif [ `uname | grep -i cygwin` ]; then
  DIST=Cygwin
else
  echo "Can not identify the platform"
  exit -1;
fi

Having all of these platforms supported by a particular package would be
upto the octave-forge maintainer on those platforms feeding back the
necessary code for the DESCRIPTION files.

D.