Quoting David García Granda (dgra...@gmail.com):
> Uhmmm... I think what Andreas proposes (newer first ;)) would be
> interesting for us as some distributions (like Debian stable) wait
> more time to include packages in their lifecycle and lack of
> flexibility here may produce headaches (I remember some "future"
> statements time ago) to get pytrainer package included in them. Any
> comment from Noèl or Christian?
pytrainer (or packages it depends upon) will *not* be upgraded in
Debian stable. That would go against the Debian policy of not
upgrading versions in the stable (aka released aka "squeeze" ATM)
version of the distribution.
Debian squeeze has pytrainer 1.7.2 and will thus stick with it.
Of course, we're currently working to prepare the *next* release of
Debian (codename wheezy). This work is done in the "unstable" branch
of the distro. When packages reach sufficient stability (10 days
without RC bugs and all dependencies satisfied in the testing branch),
they enter the "testing" branch....which is "the release under
preparation" branch.
So, we will there have the next released version. Hopefully, we also
have there the latest (or very recent) version of libraries pytrainer
depends upon...but that should be checked.
This was about "official" packages. Those we have in the released
distribution.
So, well, disruptive changes in dependencies are OK with us as long as
we can satisfy the dependencies.
Of course, keeping backwards compatibility should be done as much as
possible, for instance to allow people to use "backported" versions of
packages in the stable branch ("backported" is "the new package, from
unstable, recompiled for stable").
For popular apps, there is a demand for "recent" versions of
applications to exist in the stable branch of the distro. In Debian,
we solve this with a semi-official part of the distro named
"backports" (http://backports.debian.org). Those are packages from the
"testing" branch (aka the next release) which are rebuilt for the
"stable" branch. I think it is good to keep this doable. It will for
instance allow Noèl or me to create backported packages of latest
pytrainer for Debian stable.
So, if there are planned changes in dependencies, then we should check
if they're disruptive with what we have in both our "stable" and
"unstable" branches of Debian. I read about
"python-sqlalchemy". Currently, we don't have such dependency. We
currently depend on:
Depends: python, python-support (>= 0.90.0), python-libxml2, python-lxml,
python-pysqlite2, python-glade2, python-gtk2, python-matplotlib, python-scipy,
python-numpy, gpsbabel, iceweasel | firefox | abrowser, python-webkit,
python-soappy, zenity
I understand from this thread that new dependencies might be
needed. Am I right (I don't follow the mailing list for a long
time...sorry if this was mentioned earlier).
To be complete: for Ubuntu, the picture is mostly the same (with a
different release cycle). Please notice that pytrainer packages in
Ubuntu are, as far as I know, exactly the same than Debian packages
(just like 90% of the distro is).
pytrainer should really take care of being not disruptive with Ubuntu (very
obviously popular distro among its target users), down to the latest
LTS version of it (as of now 10.04).
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Pytrainer-devel mailing list
Pytrainer-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytrainer-devel
