octave-maintainers
[Top][All Lists]
Advanced

[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: Fri, 15 Sep 2006 09:54:27 +0200
User-agent: Thunderbird 1.5.0.5 (X11/20060817)

Thomas Weber wrote:
> Hi, 
>
> I'm somewhat late to the party, but a short explanation of 'creating
> Debian packages'.
>
> We only specify the build-dependencies (say: libreadline-dev). The build
> tools on the autobuilders then figure out the dependency upon
> libreadline for themselves (by looking at the output of ld, I guess).
> So, for Debian a BuildRequires is enough. 
>   
In fact the same is true for RPMs with the AutoPreReq stuff that is
implemented.

> But please note that we might end up generating this dependency lines by
> hand. Other people must be able to rebuild our packages, so we don't
> fiddle with the dependencies at build time (by build time I mean the
> build on the autobuilders). 
>   
Thats fine by me, but having the dependencies for at least one
distribution in octave-forge means that future packagers just have to
figure out what is the equivalent dependency for their OS, rather than
have to chase them down by trying to build the code themselves, with the
chance that they might have the dependencies already installed and so
not realize that a dependency is need causing some future person much pain.

Then the question is which is the privileged platform that will have
their packages built correctly automatically. I still tend towards
allowing distribution dependent code in the DESCRIPTION file, with an
understand that they are hints to the packager and not carved in stone.
So in general the octave package might have in its DESCRIPTION file

BuildRequires: libtermcap-devel

and then the packagers can adapt this to their own platforms by hand.
Going from there to

BuildRequires: libtermcap-devel [Mandrake Mandriva] libtermcap2-devel

doesn't seem a big or costly step to me.

> The R packages in Debian have their Dependencies-lines manually created
> (at least if I understood Dirk correctly). 
>   

The script Soren sent it seem that the last step is a build of the
package itself., prior to any manually inserted dependency lines. I
presume then that this is to give some idea to the packager what the
dependencies are.

>
>   
>>> 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.
>>>       
>
> It's not that easy. What if somemone has an older version of Fedora, but
> a newer library than the one shipped with that distribution is needed?
>   
My first thought is tough, they can upgrade. Though serious, I think
this is not a likely situation to occur, we are talking of a hand-full
of packages only at the moment, and for example the octave gsl bindings
check the library version and only build the functions they can. So
allow this is technical an issue, in practice it might not be.

> All in all, I think you shouldn't try to reinvent rpm or deb. Make it
> easy to extract the necessary lines, but I wouldn't go for
> ready-to-be-built packages for every distribution. 
>   

By its nature the ocatve packages are a re-invention of rpm and deb in a
certain sense. If they weren't there would be no automatic process to
convert from an octave package to an rpm or deb :-)... I don't think we
can go for ready to build for all platforms, and in fact I refuse to
try. I think the goal is making the packagers life easier, not replacing
them..

Cheers
David

-- 
David Bateman                                address@hidden
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



reply via email to

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