Ryan Ollos <rjo...@gmail.com
I'm commenting as the maintainer of trac packages in pkgsrc (since about
2007/2008), which is a multi-OS packaging system that is native on
NetBSD and SmartOS (an Illumos variant) and which works on FreeBSD,
OpenBSD, probably DragonFly, Linux, OS X, solaris/illumos, and also more
obscure platforms like AIX, IRIX, and Cygwin.
The trac package does not depend on svn or git. By default it depends
on sqlite3, but one can switch to pgsql (via psycopg2).
> The issue of which versions we support has come up in the following case -
> Subversion 1.6 is no longer supported (1) and I'm considering implementing
> a change that would be supported in Subversion 1.7, but not in 1.6 (2). It
> would be great if we could drop support for Subversion 1.6 in Trac 1.2, but
> I feel there should be a formal process for approaching this.
This is tricky. It's not about pkgsrc - I have 1.8.11 installed now,
but it seems people like to keep servers at older versions. It does
seem reasonable for 1.2 to drop 1.6, and let 1.0.x keep working with
> The list of platforms I came up with is: Ubuntu, Debian, Red Hat / CentOS,
> Fedora, Suse / OpenSuse, FreeBSD, Windows, Windows Server, Mac OSX.
NetBSD, and I'd say Illumos. (I have trac in production on NetBSD on
multiple servers, with both svn and git).
> In general I think it's sufficient to say that we will aim to support the
> most recent LTS release with each major release of Trac, provided the LTS
> release has been out for a while, say 6 months. I'm most familiar with
> Ubuntu and Debian, so I would say that we should aim to support Ubuntu
> 14.04 and Debian 7 with the 1.2 release of Trac.
The concept of a single release only really applies to Linux
With pkgsrc, there is a new stable branch every quarter. trac will be
ok if it works with the versions of dependencies that are in the same
stable branch. As long as you are ok working with a stable release of a
dependency that was current (*actually released* with a tarball and a
non-beta designation) 1 year ago, I am 99% sure there will be zero
issues. Probably even for 3 months.
Then, there are multiple stable branches of the OS. With NetBSD,
there's 5, which is old but supported, 6 which is current, and 7 about
to be released. But I am sure trac 1.0.x is ok on 5 (I run it) and
surely it is fine on 6. So this is not actually that tricky in practice
for trac. The usual packager-friendly guidlines of not demanding
bleeding-edge versions and not demanding exact matches apply.
It's definitely ok to only support python 2.6 and 2.7. pkgsrc has both
and 2.7 is normal and 2.6 for those who have to run old code.
A big question you didn't ask is databases. I use postgresql, because
it's been solid for a long time and has had real transactions. I have
found sometimes that when I upgrade postgresql to a newer version I have
trouble with some plugins and have e.g. to make the SQL more careful
about types. Surely others use mysql, but I am less familiar with
versions, and my impression is that the project does not recommend it.
Probably sqlite3 does not have issues with different versions.
For postgresql, I know mastertickets and sensitivetickets work with
postgresql 8.4. I have not tried newer. I would probably recommend 9.2
for new installs.
> What I have in mind is to compile a list of platforms we support, and then
> list the versions of the dependencies provided by the platforms. From that
> we can generate the table of supported dependencies. If this seems like a
> good plan, I'm hoping that those familiar with the platforms can help
> generate the list.
On pkgsrc from the 2014Q4 branch (released in the last days of 2014):
and not apparently required, but FYI:
But, I'm pretty sure that pkgsrc, with the quarterly update model and
no LTS concept, will not be trailing edge on any dependencies.
I deal with a lot of upstreams. Trac core has not been an issue, so I
think things aren't broken and it's good to tread lightly on deprecating
svn 1.6. It's fine to deprecate python 2.5 (and 2.4).
I often see people with ancient RH/centos systems who for some reason
want to run really old base code like python but also run new things
like trac. I think this doesn't make sense; one should either keep up
or not keep up, but not have it both ways. One can install pkgsrc on
such a system and have a trac/python (and web server, database) install
that is up to date, even if the base system is old.
With the plugins, I'd like to see them each have real releases with
version numbers and tarballs. pkgsrc is basically opposed to packaging
git snapshots, and it's a bug in the current git culture that saying
some hash is stable is viewed to be as good as a real release. This has
gotten better, but seems not 100% ok across the variety of plugins.
Plus, I'd like to see plugins tested with recent pgsql (and mysql).
That's my packager rant -- thanks for asking to hear it!!!