octave-maintainers
[Top][All Lists]
Advanced

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

Re: PKG wishlist


From: David Bateman
Subject: Re: PKG wishlist
Date: Thu, 31 Aug 2006 16:50:15 +0200
User-agent: Thunderbird 1.5.0.5 (X11/20060817)

Søren Hauberg wrote:
> ons, 30 08 2006 kl. 23:40 +0200, skrev David Bateman:
>   
>>> fre, 25 08 2006 kl. 17:20 +0200, skrev David Bateman:
>>>       
>>>> Can and should we change the package manager to enforce that the name of
>>>> the package corresponds to the file name? This would be easy to enforce
>>>> in pkg.m, and not more harder in octave-forge to build the package from
>>>> DESCRIPTON(name:) rather than the directory name.
>>>>         
>>> This makes perfect sense to me, and the code looks good. Thanks for
>>> doing this.
>>>       
>> Except that there is a problem with the whole concept of bundles as you
>> recently introduced. I've just tripped over this while trying to write
>> code to test a package and its dependencies within octave-forge. If
>> there is more than one package (as indicated by more than one
>> subdirectory in the archive) then there is no way for the archive name
>> to correspond to the name of all of the packages.
>>
>> The way I see of dealing with this is enforcing that a package can only
>> have a single sub-directory. A bundle would then be another archive,
>> that is an archive of packages, and not the sub-directories contained in
>> the packages. Should we treat bundles of such bundles? If you are ok
>> with this then I'll take a go at implementing it.
>>     
> Doh! You're right. At first I simply wanted a bundle to be an archive of
> packages, but I thought it would be to much work to implement. This is
> why I simply used subdirs in the archive.
> But what about the problem that made you enforce packagename==filename?
> What happens if a bundle doesn't include all it's dependecies? Will that
> give you any problems?
>   
I don't see that this is a problem. The current code reads all of the
description files of the packages to install and checks if all
dependencies are satisfied. Something similar can be done with a bundle.
However, I forgot to mention that for the "make check" code in o-f, I'd
like to implement a call "[self, all] = pkg('depends', <pkg>)" call,
where "self" is the dependencies of the package and "all" is the
dependencies of the package and the dependencies of all of the dependent
packages recursively. This call would not install the package.

The goal of this call would be to group the dependency checking in the
octave pkg function, rather than have two different implementations,
thus reducing the chance of bugs.
> We could introduce an optional OS keyword in the DESCRIPTION file. If
> the DESCRIPTION file contains
>   Operation System: MacOS X
> then RPM builders could simply grep the DESCRIPTION files to see which
> they should build.
>
>   
Why, not. Trivial addition that supplies supplemental information to the
packager.

>> 2) Complete the README in the o-f bundles, and add some post-install and
>>  pre-uninstall m-files to the bundles so that the RPM, DEB packages and
>> create a binaries package (everything in <pkg>/inst) and use octave
>> itself to deal with the install and the update of the octave_packages
>> files. This will probably also need code like the "make check" stuff to
>> allow create of the binaries package in a sandbox.
>>     
> Perhaps we should have a
>   pkg build <package name>
> command that compiles the .cc files in the package, but doesn't install
> the package. I don't know anything about rpm/deb but I assume that
> having a bunch of files that just needs to be copied is fairly easy to
> package.
>   
You don't need this, though it might be useful. What I did for the "make
check" code is create a sandbox for the code to run in with the
OCTAVE_PATH, etc environment variables and an appropriate .octaverc file
to give the package directory. Something similar might be done to create
a binary package, though the structure of the installed files would need
changes (ie files in <pkg>/* moved to <pkg>/inst and files in
<pkg>/packinfo/* moved to <pkg>/) this would be fairly trivial to do in
a build script we might supply with the bundles..

>   
>> 4) Automatic webpage creation for each package from the description file
>> with inclusion of any html docs that are found in the package
>>     
> I think I have some code for this somewhere -- I'll browse my archives.
>   
Good, I'll do nothing here then

>   
>> 7) clean out some of the unnecessary stuff from o-f (??)
>>     
> But this is a fairly small issue, right?
>   
I try to take care of it while doing the rest, and its not always
obvious where the dead wood is..

>   
>> Want to tackle some of the points above? Octave-forge is really in a
>> state far from a release at the moment...
>>     
> Sure, I think I can find some time over the weekend. Is there anywere I
> should focus? I don't know about rpm/deb creation, but if you want I can
> read up on this...
>   

Either the automatic page creation or the bundles/dependency checking
code in pkg.m. I'll probably tackle the bundle code myself and I can't
advance elsewhere till that is addressed, but you can take the
dependency checking stuff if you want.. Just tell me where and I'll stay
away.

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]