[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
Sat, 1 Dec 2012 16:42:00 -0800 (PST)
----- 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
>> 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
>> 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.
>> 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.
> version definition
> The current implementation only accepts versions on the format x.y.z. This
> not allow for dev versions, beta or release candidates releases such
> x.y.z+, etc
> 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
> 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
> 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
> A bundle is a _usable_ set of _compatible_ packages.
> On packages vs Octave itself version - I _strongly_ suggest _not_ using
> 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
> with different Octave version. What I suggest is similar to Linux kernel
> - by default they refuse to be loaded into a different kernel version, by
> can be forced to.
> Since developers' resources are limited, I suggest to firstly implement
> refusal, and later, it it's really necessary, forcing.
> Help-octave mailing list
And the issue Octave developers haven't yet addressed (or I missed it ?) is the
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.
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.
Re: [Pkg-octave-devel] mkoctfile not installed in Wheezy, Thomas Weber, 2012/12/02