Re: [Gnumed-devel] Re: Debian lenny required for client 0.2.8.10-1 ??

[Karsten Hilbert]

On Tue, Sep 02, 2008 at 09:29:23AM -0700, Jim Busser wrote:

> But downloading and running the client from tarball will not resolve  
> dependencies

It doesn't need to. The code does not use any runtime
features only available on testing. It is just that the
package itself cannot be installed on Stable because it
relies on install time features.

I have refrained from using runtime features in 0.2.8.x very
much because people can thus still use it on Stable.

> Requriing people to use testing is not a good solution

Restricting ourselves to Stable is an even worse solution.
GNUmed evolves too fast to rely on Stable features alone.
Witness the flood of antique-Ubuntu bug reports -- and
Ubuntu is releasing way earlier than Debian proper.

> when we know that 
> -- at least for servers --- it will be wiser for them to run on stable.
There's no problem staying on Stable with servers.

> So we need to clean up what is needed to not-too-painfully help apt-get 
> install things which may be needed from testing.

Current Testing being in freeze and to be released as Stable
Real Soon Now puts big question marks around this suggestion.

After Lenny has become Stable there will be an interval of
time where our code will be installable (via backports, in
mixed Lenny/New-Testing, or as tarball) and runnable on that
platform. However, at some point in time we'll depart from
that possibility - likely fairly early because we want to
partake of Testing features, say wxPython 2.8. (Oh, wait,
that made it for lenny) which aren't available in Stable.


>> While this [becoming aware] can surely be done starting with 0.3 the 
>> client
>> checks for upgrades at startup and informs the user if any are  
>> available.
>
> What is it, exactly, that the client "detects" and announces?

The client checks its own version number against the "latest
available" version number(s) from

        http://www.gnumed.de/downloads/gnumed-versions.txt

If it finds a version above its own it says so if configured
as such. It can be configured to only check the branch it is
on (0.2.8.10 -> 0.2.8.11) or across branches (0.2.8.10 ->
0.3.1)

Now, this is skipping the package maintainer because it
checks for *GNUmed project* releases, not distro releases.

It would then be up to the user to ask for an upgraded
package from the distro maintainer.

Alternatively, the user can decide to start running tarballs.

> What would 
> be the links or steps between the preparation of a client-detectable 
> "release"
Editing the gnumed-versions.txt file. The URL is
configurable, too, btw, so package maintainers or even local
admins may decide to point users to a local file they edit
themselves at convenient intervals.

> Is it agreed that releases which would affect a dependency should be  
> held back from client detection until the release can be apt-gotten?
No. One reason would be that we cannot hold back release
announcements because outdated-strange-OS (think Windows)
doesn't get around to providing new packages.

> Can 
> a developer (easily) lose sight of when a client release would affect its 
> dependencies?
Sure.

> Could dependencies in testing prove unable to be installed on a mixed  
> system?
yes

> I suppose I am worrying whether clinically-needed GNUmed clients 
> may be unable to run on a mixed stable/testing system.
yes

> This would mean 
> that even if a server *could* run under stable, an IT person could not 
> confirm proper behaviour of client software (if it had to be on 
> "testing") and server software (on stable) on a single machine.
Yes, but they could then simply setup a test server on that
very machine. The server will run anywhere the client runs.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346