[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 22:27:50 +0200
User-agent: Thunderbird (X11/20060817)

Søren Hauberg wrote:
> That syntax looks good. I'm quite sure I get the RPM field though. Is
> that the default for RPM based distros that aren't listed?

Yes, basically I'd hope that in most cases an RPM: and a DEB: keyword
might be enough. Where I see a problem with this is that

RPM: libtermcap
Mandrake Mandriva: libtermcap2

is not simple to treat properly, as how can we tell that for Mandrake
and Mandriva we don't want the first dependency but the second. Maybe
for this reason the syntax

Requires: libtermcap (> 2.0.6) [Mandrake Mandriva] (libtermcap2 > 2.0.6)
Requires: ImageMagick (> 6.2.0)
BuildRequires: ImageMagick-devel (> 6.2.0)

where the default is the first after the first ":" and DEB based
distribs can create the control file as

Build-depends: ImageMagick-devel (> 6.2.0)
Depends: libtermcap (> 2.0.6), ImageMagick (> 6.2.0)

Mandrake/Mandriva can turn it into

Requires: libtermcap2 > 2.0.6, ImageMagick > 6.2.0
BuildRequires: ImageMagick-devel > 6.2.0

and other RPM based distributions can turn it into

Requires: libtermcap > 2.0.6, ImageMagick > 6.2.0
BuildRequires: ImageMagick-devel > 6.2.0

We need to make the right compromise between clarity, maintainability
and simplicity, so I think getting this one right it might be better to
get others thoughts. Do the R packages have an automatic RPM and DEB
build process if so they must have already dealt with this and so
perhaps we should be inspired by their solution?

> Assuming you've created a script called called "build-rpm.sh" that
> creates an .rpm from a package, couldn't we simply do something like
>   ./build-rpm.sh --distro=Fedora package_file
> ? That would make the script much more simple, and it would be much
> harder to use.

I'd thought to split the generation code from the distribution detection
code in any case. A means of overriding the automatic detection makes
sense. The problem I see with your proposal is that it might leave the
user thinking that they could build the packages for one distribution on


reply via email to

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