Re: [DebianGIS] A possible Grass policy for lenny+1
Francesco:
> I was not saying we/me have the idea of supporting all of them :)
> That is simply a way to allow the use/support of more than one version
> without having to deinstall anything.
I'll comment below on multi-6.x version usage.
As for supporting multiple versions (I speak of the program, not the
..deb packaging here!), I currently have 8 different grass versions built
on my system + the debian package from b.o.... no problems.. just one
grass package installed (b.o) and the rest run directly from their build
dirs. No need to install or uninstall anything, no ld.so.conf hell.
> And what complication are you pointing?
a greater number of bytes in the debian/ dir, and a further deviation
from upstream.
> Now we have to manage by hand all paths in 6.2, 6.3 and possibly
> 6.4, as is visible on the svn repo. That's quite annoying and
> error prone. Templating for versioning would allow at least
> to manage paths automagically and one could concentrate
> only on managing new depedencies and patches which are
> always different among versions.
I found changing all the 6.3s to be 6.4s to be only a few minutes...
shrug. You can put as much effort into the packaging as you like if you
really want to, I'm just saying that I don't see the need for that work.
....
> > * Once you have 6.3.0 installed there is zero reason to keep 6.2.3
> > * Once you have 6.4.0 installed there is no reason to keep 6.3.0 or
> > 6.2.3
> > !!!
> >
> > This is because grass is fully forwards compatible at the 6.x level.
>
> I would say roughly compatible.
I would say highly (if not fully) forward compatible.
> I have scripts that work under 6.3 but needs changes to work under 6.2
note that I wrote "forwards compatible", and no need to go back.
> and viceversa
really?
> because command line back-compatility is not always respected,
please back that up with an example.
The only explicit command line breakage I can remember was due to a buggy
option which shouldn't have been there in the first place, and wouldn't
have worked anyway. (IIRC this was some time ago, pre 6.2)
Message strings can change if you are grepping something out of the middle
of a report (requiring minor tweaking to update), but that is not CLI and
typically there is flat output available in those cases which will be
format frozen and better to have used.
> some commands become obsolete, etc.
No, renamed/obsolete command are kept as symlinks or shell script
wrappers to the new names.
> New versions could introduce new problems and people could
> be interested in maintaining their current version in use
I could say the same for X.org, but only 1 version of that is offered at
a time. If folks want to run Debian/Potato let them, but don't pollute
main with redundant legacy versions.
> for legacy scripts.
as above, legacy 6.x scripts should run fine on any newer 6.x version, if
not then file a bug report for that. We have gone to a lot of trouble to
ensure compatibility.
> Note that my proposal is not depending on the _current_ roadmap, but
> adequate for _any_ prospective roadmap and change in grass release
> management.
keeping in mind that grass is a bit of a million ton glacial project...
again, I am not criticizing your proposal, just questioning the gain.
> With current situation one HAS to upgrade. With the proposed one one
> can maintain an old version and use a new one at the same time without
> problems.
my point is that you don't need to.
> The idea is allowing people to create packages for 6.any independently
> and manage only a virtual package to define what should be considered
> the default one.
as above.
if you think it will make svn-snapshot packages easier, ok.
> > There is some sense in allowing grass6 + grass7 packages on the same
> > system to run grass6 specific scripts/addons. But I rather doubt grass7
> > will be ready for lenny+1.
>
> I would not so sure, with our current prospective release times :-/
the release cycles of the two projects are not too different in that
sense.
regards,
Hamish
Reply to: