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

[Sergei Steshenko]

----- Original Message -----
> From: Sergei Steshenko <address@hidden>
> To: c. <address@hidden>; 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" <address@hidden>
> Sent: Sunday, December 2, 2012 2:26 AM
> Subject: on packahing on general and on contents of 
> http://wiki.octave.org/OEP:pkg
> 
>> ________________________________
>>  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.
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://mailman.cae.wisc.edu/listinfo/help-octave


And the issue Octave developers haven't yet addressed (or I missed it ?) is the 
following.

Suppose a mechanism to select packages is in place, i.e. there is a possibility:

foo_package comes from John
bar_package comes from Paul.

So far so good.



Now, say,

foo_package depends on doo_package
bar_package depends on dah_package
.

Where do doo_package and dah_package come from ?

Folks, again and again, _first_ resolve the whole namespace issue.


Regards,
  Sergei.



>