Re: [Pkg-grass-general] debian-gis stable
Just a few ideas...
On Wed, Jan 26, 2005 at 03:41:19PM +0100, Silke Reimer wrote:
> I would strongly vote to add all stable packages to official debian
> instead of creating a sort of branch on our repository. I always saw
> our repository as an easy effort to bundle our efforts on GIS
> related packages and to have it as one central repository for
> GIS package that are not yet debian ready - just to make it easier
> to get hold the overview over the last version of a certain package
> (we once had the problem that there were several grass packages
> around and we needed a way to coordinate different efforts to
> improve the package).
>
At this stage, I see the debian-gis repository as an experimental area
for general contribution and testing. I'd like to see future DebianGis as
a CDD, which many people see as a possible profitable future for
Debian development. We currently have a very long life cycle for
main (etch would be possible released in 4-5 years from now).
I'm quite sure Debian as we know it today will be different after
sarge, probably our monolithic archive is at its latest days by now.
But who knows?
> If we promote our repository as 'ready to use in production' we
> would have to build up a great part of the debian infrastructure to
> ensure that we have unstable only for testing purposes and testing
> for those packages that are more matured. It would be easier to use
> the official debian infrastructure to do this for us.
>
That would be a nice thing, but I'm afraid that we will have to
support stable after frozing, with backports off main archive for a
quite long period. DebianGis is a workstation-oriented project, stable
will become obsolete quite fast. For instance, grass 5.0 was almost
acceptable a couple of years ago, now it's obsolete.
> My idea has been to create virtual packages such as 'gis-server' or
> 'gis-client', perhaps even 'gis-ogc-server' etc. to get bundle of
> GIS related packages that are necessary for specific tasks.
That's right, task pseudo-packages is the way to go to simplify
installations.
Of course, all this IMVHO :)
--
Francesco P. Lovergine
Reply to: