On Sun, 10 Oct 2004, Christopher Faylor wrote: > On Sun, Oct 10, 2004 at 07:25:46PM +0200, Reini Urban wrote: > >Christopher Faylor schrieb: > >>On Sat, Oct 09, 2004 at 04:38:35PM +0200, Reini Urban wrote: > >> > >>>If not I'll put proj, geos and gdal into Libs, > >>>postgis into Database, and mapserver into Web. > >> > >>Where does Debian place these packages? Or aren't they available on > >>Debian? > > > >Some are in "Science". Some are not yet in. > > Ok. We don't have Science currently. I added it (we've been using > Debian categories as suggestions for cygwin). > > >The FreeGIS maintainers should be better able to answer this, > >because they maintain the debian and other packages: > > RedHat 7.2 (i386), Mandrake 8.2 (i386), SuSE 8.0 (i386), > > Debian 'woody' 3.0 (i386) > > http://freegis.org/cd-contents.en.html > > > >Debian itself: > > They are years behind, as with every debian package. > > Categories: http://packages.debian.org/unstable/ > > > >proj is at Science > > http://packages.debian.org/unstable/science/proj > >gdal is in Science, but has no debconf template. > >grass is in Science. > >qgis is in Science. > >postgis is ITP'd since a few years. http://bugs.debian.org/146051 > > http://www.debian.org/devel/wnpp/being_packaged.en.html > >geos is ready to be ITP'd. but not yet done. > > > >But I really don't know how they divide between Mathematics and Science. > >For example "mathomatic" as Math package is in science. Other algebra > >packages, such as octave, maxima, gap, axiom, yacas are in Mathematics. > >Also the statistic packages. > > octave is imho much more science than math. well. > >gmsh or admesh as mesh generators are in Mathematics and not in Science. > > If we can get a definitive word on what the upstream package maintainers > want, then we should use that, assuming it fits into cygwin's schemes. > Otherwise, I guess we should use whatever makes sense given the categories > available at <http://cygwin.com/setup.html>. > > cgf
Would this be the time to bite the bullet and allow package subcategories (as is already done with directories)? I see at least two ways to do this: either change the format of the Category: field to use some separator (e.g., "/") between the category and the subcategory, or do it as a two-step process -- first introduce a Subcategory: field and make upset and setup aware of it; then work on the setup logic for displaying the subcategories properly. The advantage of the first approach is that setup will immediately be able to show the subcategories, but at the cost of category explosion until they're parsed properly. The second approach will keep the setup screen the same until we're ready to switch (principle of least surprise and the like), but will require a small up-front change. Discussion? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Happiness lies in being privileged to work hard for long hours in doing whatever you think is worth doing." -- Dr. Jubal Harshaw