-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johannes Sixt schrieb:
> The most recent entry in debian/changelog is dated 2006-09-12. This is quite
> aged.
>
> Is there a knowledgable Debian developer who knows how to bring this file
> up-to-date in a meaningful way? That is, I don't want to just throw in
> today's date without any additional notices or without knowing what I am
> doing ;)
Hello Johannes,
the problem is that the debian/changelog also controls the revision number
and (signing) author and other metadata of the newest release. So, if you
add an new entry at the top, you can then just by issuing dpkg-buildpackage
create a new debian package, which you then may install into your system.
Of course, this bears the change that your package interferes in some way
with the version numbering from "upstream". I don't think this can do
any serious harm, but it may
- - cause the package manager to consider your package to be more recent
then an (actually newer) package from the Debian/Ubuntu packager, thus
missing and update
- - can as a consequence of the dependency management block other updates.
But, when the user performs an dist-upgrade, the package manager additionaly
takes the priority of packages into account and thus will remove such a
blocking package in order to perform an update for an more important package
(Cinelerra is flagged as "optional" anyway).
> Is this file of any use for our Debian/Ubuntu packagers? Or do you keep your
> own versions of the debian/ directory anyway? What's the best way to proceed
> here?
I am interested in this question to, because I probably will care for packaging
Lumiera (and Cehteh's NoBug) in the near future.
Generally speaking, Debian distinguishes two kinds of packages:
* Debian-(only) packages: They contain software which is integral part of
Debian, is maintained by the debian community and considered not of much
use for any other distro. The distinguishing property of such packages
is that there is no "upstream" outside of Debian and thus the source
package doesn't contain a diff, just the PACKAGE_VERSION.orig.tar.gz
and the PACKAGE_VERSION.dsc. Also, the version number usually doesn't
contain an additional debian-revision number.
* all other packages: These are always based on an official release tarbal
(which may be either an officially published and downlodable release or
pulled literally from an "upstream" CVS, SVN, Git,...). Then, the
Debian packager adds the debian directory or updates an existing
debian directory, maybe applies additional patches/fixes (or includes
them to be applied by the debian build process). All these changes
are delivered as an additional PACKAGE_VERSION.diff.gz and referred
from the accompaning *.dsc. Moreover, the Debian packager often creates
a series of debian-revisions based on a single upstream tarball.
These revisions may contain additional patches/fixes, tweaks to the
build system or just documentation updates. They are marked by an
additional numbering which is appended at the end of the upstream
versioning scheme with a "-"
Based on this informations, I personally see two possible strategies for the
upstream developers. It is clear that the Debian packager is bound to deliver
a *.diff.gz, and he is bound to review and possibly change the debian/changelog,
debian/control and debian/rules (=makefile). So the upstream developers could
(1) either leave out the debian subdirectory completely
(2) or follow the Debian packager with respect of the debian subdirectory
I am rather inclined to do the second, as the fact that a basically usable
debian subdirectory was available in SVN helped me a lot with getting started
some years ago. But to do so, I'd rather try to grab me a reasonable "official"
and recent Debian package of cinelerra and use the contents of the debian
subdirectory as found after applying the *.diff.gz as-is, without trying to
maintain an additional changelog. Its the packagers job to do so.
Especially for Cinelerra there is a twist. Over the time, quite a lot of build
tweaks where floating around. For example, over a long period of time, the
debian/rules as contained in the SVN caused problems for me on AMD64, and more
recently, I see lots of little tweaks beeing necessary to make it build here
and there. So it's not clear for me what would be the best choice of "official"
Debian package to follow. But at least you could have a look at the debian/rules
with your knowledge regarding the build process, if you spot any obvious
ommisions or mismatches there.
And, btw. I like Ubuntu much and use it on some of my machines, but with regards
to packaging, for the upstream developers I'd favour Debian as a point of
reference. (For Lumiera, we'll try to do the same).
Hopefully these informations where helpful and I didn't bore you ;-)
Cheers,
Hermann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Moz
