[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: on packahing on general and on contents of

From: Carnë Draug
Subject: Re: on packahing on general and on contents of
Date: Sun, 2 Dec 2012 09:43:51 +0100

On 2 December 2012 01:26, Sergei Steshenko <address@hidden> wrote:
> Hello,
> I read what's written in , 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.

I do not understand what you are trying to suggest. The idea is to
name those trees (we are just calling them dbs for now) so you can
specify from which one you load the package or from which one your
package is loaded.

> "
> 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.

I disagree with the there's nothing wrong with not supporting it.

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.

> 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.

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.

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]