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

[Sergei Steshenko]

>________________________________
> From: c. <address@hidden>
>To: Rafael Laboissiere <address@hidden>; Ben Abbott <address@hidden>; Jordi 
>Gutiérrez Hermoso <address@hidden>; Juan Pablo Carbajal <address@hidden>; 
>Carnë Draug <address@hidden> 
>Cc: address@hidden 
>Sent: Saturday, December 1, 2012 8:25 PM
>Subject: Re: [Pkg-octave-devel] mkoctfile not installed in Wheezy
> 
>
>On 1 Dec 2012, at 17:58, Rafael Laboissiere wrote:
>
>> This discussion would be more appropriate in the mailing list of the Debian 
>> Octave Group.  Please, move it there.
>> 
>> Rafael
>
>Actually, to better keep track of ideas about how to change pkg.m Carnë 
>has set up a page on the wiki about the required improvements to its design
>I think it would make sense to discuss this topic in the "talk" page there:
>http://wiki.octave.org/OEP:pkg
>I do encourage you to post a link to this page to the  Debian Octave Group 
>mailing list as well.
>c.
>_______________________________________________
>Help-octave mailing list
>address@hidden
>https://mailman.cae.wisc.edu/listinfo/help-octave
>
>
>

http://wiki.octave.org/OEP:pkg


Hello,

I read what's written in http://wiki.octave.org/OEP:pkg , and here are some 
comments.

When in the nineties my colleagues and I devised what is called in VLSI 
development integration environment, we used the following approach regarding 
from where parts of the chip mode could be taken:

1) from the released central project tree;
2) from any designer's tree.

Released trees had names; designers' trees were strict subsets of released 
trees.

So in that respect all those "Jenny", "boss" interactions are somewhat 
artificial. A tree is a tree, and a boss is as human as Jenny.


On:

"

version definition 
The current implementation only accepts versions on the format x.y.z. This does
not allow for dev versions, beta or release candidates releases such x.y.z-rc0, 
x.y.z+, etc 
We have compare_versions in core to check for version numbers, whatever is 
decided
should be used with compare_version (or compare_version should be made to 
support it). 
"

- there is nothing wrong with absence of 'dev' versions. As we all clearly 
realized in our VLSI development world, for us, the integrators, life never 
ends. The bosses simply decide that _a_ release has bearable amount of bugs to 
be implemented in silicon; practically immediately after tapeout another 
release is created, new features and bugs poured into it.


So, don't create entities beyond the necessary (complicated versioning 
schemes), just stick to package-X.Y.Z, _but_ prepare _bundles_ - as you used to 
do.

A bundle is a _usable_ set of _compatible_ packages.


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.

Since developers' resources are limited, I suggest to firstly implement 
refusal, and later, it it's really necessary, forcing.



Regards,
  Sergei.