On 25 Mar 2012, at 16:56, Juan Pablo Carbajal wrote: > 2012/3/25 c. <carlo.defa...@gmail.com>: >> >>>> 1 - change the PKG_ADD in the packages >>>> >>>> 2 - patch pkg.m to handle subdirectories in a better way >>>> >>>> 3 - forbid the use of subdirectorues in packages >> >> On 25 Mar 2012, at 14:43, Carnë Draug wrote: >> >>> The idea of having this subdirectories is a matter of organization for >>> the package developers right? (Since upon package installation, the >>> user can only load either all or none of the package anyway). If >>> that's the case, I'll suggest a 4th option (maybe only temporary while >>> we can't anything better) that is to have all the subpackages in a >>> inst/ directory. >>> The source tree can differ from the tree of the >>> actual release, I believe that is acceptable. >> >> I don't exactly understand your suggestion. >> If you suggest that pkg.m should install all >> subdirectories of /inst, that is already the case, >> but adding them to path is not done automatically yet, >> option 2 was to patch pkg in order to do this. >> >> If you suggest that files be all copied in the same >> directory upo install, that is essentially option 3. >> >> which one would you like better? >> >>> Carnë >> c. > > Hi > Carlo, what Carnë suggest is not as forbidding as option 3. He > basically says that for development you can keep the subfolder > structure, but at the install time you destroy that tree and add > everything under /inst. So, multipackages are allowed, but the > installed version looks just as any other package; everything merge > together. > Geometry and Mechanics were like that not long ago, but the installed > version looks really ugly...
I see, this soultion is very simple but requires more work from the maintainer when a package is released. maybe that work coud be done automatically by adding some extra logic in the pre_install script? c. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
