[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: on packahing on general and on contents of http://wiki.octave.org/OE
Re: on packahing on general and on contents of http://wiki.octave.org/OEP:pkg
Sun, 2 Dec 2012 00:38:41 -0800 (PST)
----- 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
> 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
> 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
> 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.
Re: [Pkg-octave-devel] mkoctfile not installed in Wheezy, Thomas Weber, 2012/12/02