On Mon, 07 Apr 2008, Adeodato Simó wrote: > The new dpkg-genchanges -si heuristic of looking at the version number > of the previous entry in the changelog breaks for (long-lived) > experimental packages that merge changelog entries from unstable in > chronological order. That is, you end up with a changelog like:
Is this really a good practice? Doesn't it cause troubles to the BTS version tracking since it use changelog to creates trees of versions? It would be nice to standardize (idea for a DEP maybe?) the procedure to follow when one uses experimental to prepare new upstream version of packages in parallel to continued maintenance in sid. I know for example that the glibc team accumulates changes in a single changelog entry and they increment the version of that entry in each experimental upload. And in the end, they use that changelog entry for the first unstable upload as well. It's a simple way to make sure that you have all bug closures where they have to be. On the other hand, the BTS version tracking starts a new branch for each experimental upload since the previous experimental version number disappeared. And if you check the version graph, you'll see all those dead branches. Let's come back to our problem however. The ordering based by date renders the -v<option> difficult to understand... do we want all the entries appearing after the given version or all entries that have a version higher than the one given ? (cf #477638) If we require/assume that entries are ordered by version, then the two solutions have the same result. :) The chronological order might be the order which represents best the reality but it's also counter-intuitive in the sense that it doesn't match the upstream evolution of the software. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
