[DebianGIS] Re: Re: Re: Re: GIS tools missing in Debian?
[Giuseppe]
> Many people uses backporting, i.e., they recompile packages from testing
> in stable. Sometimes the backport is easy, sometimes it is very hard. I
> think the only good solution for this problem is asking the maintainer
> do the backport.
That is cheeting against 'a server should only use stable' isn't it?
> Some Debian action are somewhat slow, as you pointed out. I uploaded a
> new version of postgis (fixing the debian native problem) on the 15th
> December and it is still sitting in NEW with the previous upload. I
> wonder if it could be good to have binary packages for i386, amd64 and
> powerpc available in the meantime. I could create an apt repository
> somewhere for the unstable, testing and probably stable distribution.
That is very nice (really) and helpfull, I do use these different
repositories on my testing machine a lot as well as handcompile
whatever else I need, but it is not something that is considerd stable
in the true debian sense, is it?
It now seems to turn into a discussion about debian policy, and that
is a whole different subject from gdal, or missing tools, although
equally interesting.
Lets see:
I use debian for a number of reasons, but mainly because with most
distributions like Suse and Red-hat it is almost impossible to
de-install a package and re-install another version and back again.
Debian offers this feature trough its superior packaging system. It is
even relatively safe to automate the updates with a nightly cron job
(although I did loose X-windows a number of times in the past because
of it, but it never required a full install of my machine to fix and
who needs X on a server anyway?).
I do like/advocate the rigorous testing that goes into a package.
Backporting tools to stable is somewhat against the debian policy I
think: either a tool is stable, or we are testing it.
However, it is always possible to compile tools from source, or spend
some time to get packages to install in distributions where they
shouldn't, but that is not what stable is for in my view. And a
production environment will become unmaintanable if there are too many
'custom' installed applications. I'm not payed to do system
maintenance, I get payed to do software development/architecture. And
most system administrators do not hand compile tools, they install and
configure packages.
I was not in favor of choosing Fedora above Debian at all, it is
swapping an extremely stable environment with some custom apps for a
less stable/manageable environment with more recent versions of the
apps (which I mostly have to help set-up/configure myself anyway, so
I'd rather do it on debian).
The question was, should all the package maintainers provide
backports? I think not, unless they are approved and in the main
stable repository (or was that what you meant?), but speeding the
release cycle would help a lot (at least for getting packages into
testing). It is all volunteer work and debians rigorous policy
sometimes is too hard on enthusiasts, I think.
I attended an ubuntu meeting with Jeff Waugh presenting, and their
release schedule of every six months has some benefits, But his laptop
crashed horribly during his presentation, so his version of ubuntu
wasn't that stable 8-(...
So a production environment needs stable, with only 'officially
sanctioned' debian packages. Otherwise debian is degraded to the same
level of other distributions, and that is not what she needs I think.
But it would be very nice if the stable versions would be a bit more
current. However, we probably just have to put up with somewhat
outdated but very stable software ;-).
Any ideas on getting the official debian policy speeding up?
That were a lot of words for just two cents!
Cheers,
Floris
Reply to: