-----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 Mozilla - http://enigmail.mozdev.org iD8DBQFJgzBpZbZrB6HelLIRAmnKAJ42E99gpK7VFeu/Ri64kgqFOcJQ3QCgvXsh qGW+gIk9OuD5zMUjw4jI8T4= =xtmw -----END PGP SIGNATURE----- _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
