Re: GNU Health autoremove from testing
Hi Emilien,
On Tue, Jun 10, 2014 at 02:46:02PM +0200, Emilien Klein wrote:
> > 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.
OK.
> > 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...
It is always recommended to use a clean unstable chroot via pbuilder at
least once in a package creation cycle.
> > 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.
I could imagine that we could package this beta release as an
*exception* (would not even adapt the watch file to detect those beta
releases) to make sure we will be able to detect potential pitfalls.
Considering the currently low user base and the fact that gnuhealth
will be removed from testing anyway might enable us to do this for
this time.
> > 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.
I always supported your intention because I share this mindset. I just
wanted to tell you that there are people out there who might not
consider the change as a drawback.
> > Since the versioning trouble this will most probably be the fate of this
> > package. :-(
>
> Yep, I get that as well.
>
>
> Because:
> - 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.
Well, that's another option. If you are not happy about my suggestion
to use the beta version in unstable there might be a third option
inbetween: Upload the beta to experimental. If you want to reintroduce
gnuhealth again you need to pass ftp new queue again which is hard to
calculate. You also should care for the Provides/Replaces/Conflicts
path even for a short absence of the package from the Debian mirrors
because users might have installed the package on their machine without
noticing the absense. Migrating via experimental seems to be less
invasive in any aspect.
As the main maintainer please decide between these three options and I
will accept whatever you decide.
> Thanks all for your work. Now, off to other RFP/ITP ;)
:-)
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: