On 15 February 2012 10:08, Alois Schloegl <alois.schlo...@ist.ac.at> wrote: > On 02/14/2012 04:57 PM, Carnė Draug wrote: >> >> On 14 February 2012 15:49, Carnė Draug<carandraug+...@gmail.com> wrote: >>> >>> On 13 February 2012 21:31, Michael Goffioul<michael.goffi...@gmail.com> >>> wrote: >>>> >>>> On Mon, Feb 13, 2012 at 1:17 PM, Alois Schloegl >>>> <alois.schlo...@ist.ac.at> wrote: >>>>> >>>>> There is not a strict dependency between these, most parts of these >>>>> toolboxes can be used independently. There is only a very small >>>>> overlap, >>>>> namely >>>>> inst/sumskipnan.m >>>>> inst/covm.m >>>>> src/sumskipnan_mex.mex >>>>> src/covm_mex.mex >>>> >>>> >>>> This is probably the same for any other dependency: when a package >>>> depends on another, it doesn't mean it's using the full set of >>>> functions provided by that package, just a few of them. >>>> >>>>> One could make another small package (e.g. SkipNaN) out of this subset, >>>>> and >>>>> define the dependency against this newly introduced package. However, >>>>> I'm >>>>> hesitant to do this because users would need to download two instead of >>>>> one >>>>> package, and the SkipNaN-functions are only useful in combination with >>>>> TSA- >>>>> or NaN-tb. >>>>> >>>>> >>>>> What's happening if both packages are loaded? >>>>> >>>>> These functions are exactly the same in both packages, so it does not >>>>> matter >>>>> which is installed first. >>>> >>>> >>>> Besides the fact that it can be confusing for the user, that's only >>>> true as long as the 2 versions are kept in sync. This also means that >>>> whenever you make a change to one of those 2 MEX files, you'll have to >>>> release both packages at the same time and make sure to tell those >>>> users who happen to have both packages installed that they need to >>>> upgrade both of them (otherwise you don't know which version the user >>>> will end up using). >>> >>> >>> I agree with Michael. As an example, the image package has the signal >>> package as dependency because of one single function. >>> > > I see your point, let me think about how to re-structure these two projects. > As far as I see it, nothing is broken at the moment. Usually, I do > simultaneous releases, and the overlapping functions are pretty mature. > > I would like to lower the number of different releases. Would it be an > option to put TSA+NaN into a single package and having an option to pkg for > installing only one or the other part ?
I'm not aware that such option exists in pkg and can't think of an easy to implement such thing on it. I have thought before of making pkg load sections of a package in a similar way how some perl modules work but I don't think there was much interest and I start to think it would be too much for most of octave needs. >> I'm a bit confused now. The NaN package already is a dependency of tsa >> so why the doubled functions? > > It has not been my intention to define such a dependency. Where is this > dependency defined? In the DESCRIPTION file: Depends: octave (>= 2.9.7) Depends: NaN (>= 1.0.0) see here http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/tsa/DESCRIPTION?revision=9625&view=markup and here http://octave.sourceforge.net/tsa/index.html Carnë ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
