[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GNU Health autoremove from testing

Le 10 juin 2014 13:24, "Andreas Tille" <andreas@an3as.eu> a écrit :
> Hi Emilien,
> many thanks for your continuous work on gnuhealth package.
> On Tue, Jun 10, 2014 at 12:34:56AM +0200, Emilien Klein wrote:
> > > - only initialize a limited number of GNU Health Tryton modules, point 2 in [0].
> >
> > Since the Tryton Debian package isn't creating a database as part of
> > their packaging efforts, they never hit this issue (which, as I've
> > explained, I've never seen myself, but piuparts somehow does). Based
> > on the various discussions with the Tryton Debian maintainer, I don't
> > expect the Tryton package will start creating its own database anytime
> > soon, and as such they will not see/fix this bug. I will mention this
> > one more time for good measure.
> I'm not sure whether I'm fully understand this since I have no idea
> about Tryton but if you think there is a hidden bug in the Tryton
> packages it would make sense to report it.

I agree, but at this point I have no way of reproducing it. I will nonetheless report the bug on the tracker.

> > Starting with version 2.4.1-3 of the GNU Health package in Debian,
> > there will thus only be one binary package (`gnuhealth`) produced,
> > which will contain the server-side components (Tryton modules) and
> > nothing else.
> I wonder whether you committed your last status of SVN since the package
> does not even build in thie form.  I think we now have serious trouble
> since
>   Build-Depends: ...
>                tryton-server (>= 3.0~),
>                tryton-server (<< 3.1~)
> is not fullfilled in unstable any more (and we need to create packages
> against an unstable chroot.

On my development box, I haven't updated the tryton-* packages, that's why I'm able to build it correctly. But I understand the issue...

> And yes, I have read (but not fully
> understood) the Tryton version discussion with its unfortunate outcome
> for gnuhealth.

The final next version will be released in one month (July 6th). A beta was released last weekend, which works with Tryton 3.2.

> There is another issue why I'm asking whether you commited your
> last status since you should provide a smooth upgrade path from
> previously installed packages saying
>    Provides: gnuhealth-server, gnuhealth-client
>    Replaces: gnuhealth-server, gnuhealth-client
>    Conflicts: gnuhealth-server, gnuhealth-client

I did not add the replaces/conflicts statements, thanks for catching that.

> > I am a bit sad to remove what I still consider to be a functional and
> > user-friendly packaging:
> I can perfectly understand this.  However, we have other examples like
> for instance GNUmed where even upstream prefers a manual database setup.

I somewhat understand this state of mind, but I don't share it. We (as in upstream developers and sometimes Debian contributors) are way too technical. There is a huge fraction of the population that doesn't know, and frankly doesn't care about all that technical voodoo we are involved with.
My vision is:
- Provide sane defaults (including a ready-to-use database setup) for most of the users
- Allow more technical users to opt-out of the default setup, and customize as they please.

In my opinion, dbconfig-common does it the right way: the first question you get asked is if you want to have the database managed by the package.
If you answer no, you're done, and can jump into the config files and the database setup.
If you answer yes, the package sets up the database exactly as is explained on upstream's wiki page on how to install their software (including up to the user under which the service runs, and the default modules that are activated for you). You just have to enter your chosen password, and once logged in you can start customizing the installed modules to your liking.

> > But on the other hand I'm not that sad, since:
> > ...
> :-)
> > The new version 2.4.1-3 is pushed to Subversion. Could one of the
> > Debian-med DDs please upload it to unstable? (will close the Serious
> > bug #748561 which, if left open, would mean the complete removal of
> > gnuhealth in sid in less than 2 weeks).
> Since the versioning trouble this will most probably be the fate of this
> package. :-(

Yep, I get that as well.

- Each GNU Health version depends on a very specific version of Tryton
- The releases of GNU Health will always lag a significant amount of time (at least 2-3 months) behind Tryton's new version
- It doesn't make sense to package beta (potentially unstable) versions of GNU Health just because a newer (potentially more stable) version of Tryton has been released

I suggest:
- The GNU Health package be dropped from the Debian archive.

I will wait for a few days, to make sure nobody on the list objects, after which I'll inform upstream and the Tryton Debian maintainers about this.

The Debian source package can still remain in our version control, should someone want to build it for it's own local use, but we can't support the version requirements in the current state (and forcing the Tryton Debian maintainers to create separate binary packages for each new version is not sustainable, nor fair to them.

> > The packages gnuhealth-server and gnuhealth-client will have to be
> > removed from sid (and from testing once the new package migrates to
> > testing).
> The removal of the binary packages is automatically done once the
> package with the changed binary package names will be uploaded.

I guess we can just wait for the autoremoval period to lapse, and the package will be removed automatically.

Thanks all for your work. Now, off to other RFP/ITP ;)

Reply to: