Gilles Chanteperdrix wrote:
> Shipping the xenomai tarball with the debian directory has a real added
> value: it allows people to build debian package without anything else,
> this is an unofficial package, of course, but it can be built before the
> Debian patch is generated.

Well, for people who catch the package within the few hours between
Xenomai release and the Debian version of it. ;-)

> IMO, it would make your life easier if you considered the debian
> directory part of the Xenomai package, and start working from this
> directory. If you ask for it, we can probably even give you write
> access to the repository, so that the debian packaging effort is fully
> integrated to Xenomai.

As discussed earlier this year: Every Debian package is a (small) fork
of the respective "upstream" release, with own Debian release numbers
between upstream releases, e.g. 2.4.4-1 and 2.4.4-2. Maintaining this at
xenomai.org would require branches on every (minor) Xenomai release,
e.g. 2.4.3 and 2.4.4 (besides me having repository write access),
because Debian revisions usually come out more often than "upstream"
versions (as you have seen 2.4.3-1 ... 2.4.3-7). Therefore, I prefer
maintaining it at Debian like most other packages. We already have
"trunk" and the stable release branches at xenomai.org. The above would
require an additional level of branching, maintenance and
synchronization work.

Another solution at Debian is called "native" packages where Debian
revisions and upstream versions are synchronized (i.e. no separate
Debian revisions). The problem here is that at every point in time,
Debian can decide to do a new revision (e.g. within a few hours on
security fixes) which may not be in the interest of other xenomai
maintainers. E.g. this way, Debian would decide when 2.4.5 and 2.4.6 (or and will be released. This doesn't scale well with the
number of Linux distros. ;)

For non-native packages in Debian (as Xenomai is currently), the debian/
directory is separated out into the .diff.gz patch which is good for
seeing how e.g. debian/rules looks like. If I would take the current
"upstream" tarball and only patch debian/rules in the diff.gz, the
resulting contents of the file is no recognizable from the patch alone.
Therefore, this is not common practice in Debian.

Further, it's not only me who works on Debian packages. Sometimes, when
I'm not available, one of the other 1000 Debian developers will do
Debian adjustments to the xenomai package in Debian. I guess you don't
want to give all of them write access to xenomai.org. ;)

So you have the choice between the following possibilities:

1) Leave the process as it is (Debian using the upstream tarball,
stripped from debian/*, and adding an own debian/* in a separately
shipped patch)

2) Give me (and maybe Debian as a whole) write access to Xenomai.org and
the right to branch at every "normal" Xenomai release, doing Debian
revisions. Problem here: Additional work for Debian because not only
Debian revisions must be done but also synchronization to the v2.4.x
(stable) brach and trunk. (I.e. changes are most often in 3 places)

3) Give me (and maybe Debian as a whole) write access to Xenomai.org and
the right to do xenomai releases whenever Debian wants (i.e. "native"
Debian package)

I guess you prefer (1)? ;-)


Xenomai-core mailing list

Reply via email to