[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Bateman
Subject: Re: Bug with pkg if only a single file is installed
Date: Thu, 14 Sep 2006 21:26:58 +0200
User-agent: Thunderbird (X11/20060817)

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
elif [ -e "/etc/mandrake-release" ]; then
elif [ -e "/etc/fedora-release" ]; then
elif [ -e "/etc/redhat-release" || -e "/etc/redhat_version" ]; then
elif [ -e "/etc/SuSE-release" ]; then
elif [ -e "/etc/debian_version" || -e "/etc/debian_release"]; then
elif [ -e "/etc/ubuntu-release" ];
elif [ -e "/etc/slackware-release" || -e "/etc/slackware_version" ]; then
elif [ -e "/etc/yellowdog-release" ]; then
elif [ -e "/etc/gentoo-release" ]; then
elif [ `uname | grep -i mingw` ]; then
elif [ `uname | grep -i cygwin` ]; then
  echo "Can not identify the platform"
  exit -1;

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]