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

[David Bateman]

Søren Hauberg wrote:
> I'm not sure I understand the problem, and I don't see how the patch
> solves it (I've had a loong day at work). 
>   
I didn't try to understand the problem. I just saw that at the point I
made the modification, under the circumstance where there are no files
in inst in the original package, and in fact no inst directory, and
there is a single oct-file built, the directory desc.dir is not created
at the point I made the modification. The result is that the single
oct-file is copied to a file called desc.dir rather than into a
directory called desc.dir. Ok, its a rare circumstance, but the
combinatorics package has exactly this situation.

> Basicly you want to add
>   mkdir(desc.dir)
> to the function 'copy_files'. The way I read the source (it's been a
> while since I wrote it) the function 'prepare_installation' should've
> done this already. I don't quite see what this has to do with only a
> single file needs copying.
>
> I do however see a potential bug, that your patch fixes. If you install
> a package that replaces an old installation (an upgrade) things will
> fail (I think). The following will happen:
>   1) 'prepare_installation' will create the desc.dir directory.
>   2) 'uninstall' will remove the the desc.dir directory.
>   3) The installation will fail because desc.dir no longer exists.
>
> I think this is the bug your fixing. So I think the patch should be
> good, except the function 'prepare_installation' shouldn't create the
> desc.dir directory if the patch is accepted.
>   
Ok, I'll make the change you suggest. I've also identified another
problem. Shouldn't we copy COPYING to <package>/packinfo? This caused me
a issue for the RPMs in that I created a binary octave package from the
installed package by copying all of the files to either <package>/ or
<package>/inst, and as COPYING was missing the binary package failed to
install. Making that modification to pkg.m I now have an automatic rpm
build process from the DESCRIPTION files, at least for packages that
don't have external dependencies.

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?

D.


> Søren
>   


-- 
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