On 02/15/2012 02:04 PM, Carnë Draug wrote: > 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ë
DESCRIPTION file of the released tsa-4.2.2.tar.gz does not contain the dependency on NaN. Are there any requirements how the released packages and the files on octave-forge repository have to match ? If there are, I've not been aware of these. If it is required that a specific pkg-release must match with some subdirectory in the repository, than also the repository need to be re-organized. Alois ------------------------------------------------------------------------------ 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
