>> Below a suggestion for the packaging structure: >> regarding addon packaging. We can create packages like >> grassaddons(full addons) >> grassaddons-imgagery >> grassaddons-vector >> grassaddons-raster >> grasssaddons-general I question when looking at : http://trac.osgeo.org/grass/browser/grass-addons
I wonder: * why is there a separate branch per major grass version? * what is the policy for backwards / upwards compatibility? * shall we instead of grouping by command type group by version? > if you do it, please name the pacakges like "grass-addons-*", > and install to /usr/lib/grass64/addons/. We'd have to patch our > lib/init/init.sh in the main ubuntu package to add that dir > to the GRASS_ADDON_PATH if it existed on the system. Why do we not make this default, then? > I'd base the decision on if to package them all together or > in groups based on how big the resulting package was. if it's > just a couple of MB, keep it simple in one pkg-- note for > official debian packaging all the docs and help page images > would need to be split out into another platform-inspecific > -data &/or -docs package(s). So your 4-5 packages above grow > to 12-15 of them.. for a weekly ppa build it doesn't matter > though. (the reason for that on Debian is to avoid duplicated > space in the archives since 11 different hardware platforms, > each needing their own binary pkg but can share the -data one) Let's get the thing going on experimental basis and then see how we could organise it. _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user