This is the mail archive of the
mailing list for the Cygwin project.
Re: pre-ITP: New category Gis?
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
> >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>.
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.
|\ _,,,---,,_ firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ email@example.com
|,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