[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
on packahing on general and on contents of http://wiki.octave.org/OEP:pk
on packahing on general and on contents of http://wiki.octave.org/OEP:pkg
Sat, 1 Dec 2012 16:26:04 -0800 (PST)
> 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>
>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.
>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:
>I do encourage you to post a link to this page to the Debian Octave Group
>mailing list as well.
>Help-octave mailing list
I read what's written in http://wiki.octave.org/OEP:pkg , and here are some
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
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.
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,
We have compare_versions in core to check for version numbers, whatever is
should be used with compare_version (or compare_version should be made to
- 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
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.
Re: [Pkg-octave-devel] mkoctfile not installed in Wheezy, Thomas Weber, 2012/12/02