On 6/1/2012 4:49 PM, Robert T. Short wrote: >> > The solution is simple enough. If you insist on using padarray in > marcumq then padarray needs to be moved out of image. As someone said, > image could depend on signal but signal depending on image makes no sense. > > More specifically padarray is really a general purpose function. > Shouldn't it live in a general purpose package? I personally don't see > anything wrong with sensibly structured dependency trees. On the other > hand I never, ever install an entire -forge package so I am probably not > the right person to make such a comment. > > Bob >
as package maintainer for cygwin, I can tell you that circular dependency are wrong. Make the creation of binary packages a mess. padarray in general purpose is an acceptable solution. Anyone taking care ? Marco ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
