Re: on packahing on general and on contents of http://wiki.octave.org/OEP:pkg

[Sergei Steshenko]

----- Original Message -----
> From: Carnë Draug <address@hidden>
> To: Sergei Steshenko <address@hidden>
> Cc: c. <address@hidden>; Rafael Laboissiere <address@hidden>; Ben Abbott 
> <address@hidden>; Jordi Gutiérrez Hermoso <address@hidden>; Juan Pablo 
> Carbajal <address@hidden>; "address@hidden" <address@hidden>
> Sent: Sunday, December 2, 2012 10:26 AM
> Subject: Re: on packahing on general and on contents of 
> http://wiki.octave.org/OEP:pkg
> 
[snip]

> 
> Just recently I made release 2.0.0 of the image package but before I
> wanted to do a release candidate. As pkg limits to x.y.z I instead had
> to do releases 1.9.90 to 1.9.95. The fact that I needed to make 5
> release candidates, does show that such is needed. These were not
> stable releases, not meant for production, just testing. A release
> number is misleading.
> 
> Some users like to use the dev version. When do that, pkg will still
> show the number of the last stable release. I save the package version
> number after analyzing the data so I can go back and replicate any
> analysis done. If I do that from the dev version, that's just the
> wrong result.
> 

There is nothing wrong with releasing to the _public_ foo-1.9.95 and then 
foo-2.0.12 - all versions in between are development versions which only 
developer has access to.

As simple as that.

>>  On packages vs Octave itself version - I _strongly_ suggest _not_ using 
> packages from earlier Octave versions. Nobody can tell which interfaces are 
> compatible and which are not. It's like with a Linux distro - new version is 
> not only a new kernel version, but a new bundle of libraries.
>> 
>>  I.e. technically a package should know with which Octave version it has 
> been built and installed, and, at least by default, the package should refuse 
> to 
> work with different Octave version. What I suggest is similar to Linux kernel 
> modules - by default they refuse to be loaded into a different kernel 
> version, 
> by they can be forced to.
> 
> That is the proposed design.
> 
> If a package has oct files, then the source is kept so it can be
> rebuilt  for the new Octave version. If it's just .m files, then it
> doesn't make a difference and new Octave versions can still use the
> package. And the pkg database keeps the list of dependencies so an
> installed package in 3.6.0 that requires 3.6.0, won't load on Octave
> 3.4.0, even on the same system.
> 


It _can_ make a difference. I.e. even the .m files mechanism handling can be 
changed, e.g. Octave can change directory structure. And/or if/when namespace 
issues are implemented, the namespace implementation can change.

Also, a .m file can  simply call a _program_, and the program _can_ depend on 
Octave libraries. I mean, the program can be part of the package.

Furthermore, there can be "exotic" scenarios that Octave itself needs to be 
called as that program as a separate process. In my AppsFromScratch there is a 
target for which I found it was easier to call the build script itself (with 
different command line) rather then to write code the "usual" way.



>>  Since developers' resources are limited, I suggest to firstly implement 
> refusal, and later, it it's really necessary, forcing.
> 
> Already taken care of.
> 
> 
> For everyone reading that, please bear in mind that is a work in
> progress. It started at OctConf and we are still working on it
> (there's even still question marks on it), and there's things that
> haven't been written down yet. And I'm pretty sure that when they are
> written down, they will cause more questions.
> 
> Carnë


Regards,
  Sergei.




>