On Sun, Mar 30, 2008 at 1:26 PM, Niko Tyni <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 30, 2008 at 01:45:29AM +0100, Jose Carlos Garcia Sogo wrote: > > > The only thing I am not sure is if conversion should be made in preinst > or > > postinst, before restarting daemon. What have done other packages in > such > > situation? > > Also, don't forget to keep old config file and print a big warning. > > I'm doing it in the preinst so that dpkg can prompt for changed files > when unpacking. That should take care of the backup and the warnings > too. > > > BTW, I think that git repo should go live right now. If I someday go to > get > > a new server and can recover SVN hist, we can later complete it in git, > > I just took all the packages archive.debian.org and snapshot.debian.net > had and imported them into collab-maint at Alioth. > > $ git clone ssh://git.debian.org/git/collab-maint/smokeping.git > > (s/ssh/git/ for anonymous read-only access, of course). > > The git workflow needs some work/thought here: the 'clean' target wants > to remove generated files under doc/ and git shouldn't track those in > the Debian branch. Ummm, that is a problem I have in other package, and I am not very sure about how this can be handled. Perhaps the main problem is not git itself, but git-buildpackage. Anything should be calle in the repo itself, but exported before (or at least there should be an option to do that) > > I pushed the unreleased 2.3.5-1 there too. Cc'ing #470295, in case > somebody anxious for a working master/slave setup wants to try it out. What is the pristine-tar branch intended for? I have seen that you have commited there 2.3.5, but I cannot see any difference with upstream branch I'm going to experiment a bit with using 'ucf --three-way' instead of > letting dpkg do the prompting, so this is not quite finished yet. It > should work as is, though. I have another not-yet-resolved point here. For example, for this, a topic branch would be the obvious thing to use. This is going to work here as that branch is going to be merged at a later point with master. But this approach does not work when you are implementing an upstream patch. Well, it will work, while you are woring with the source, but I don't like later to have patches in a hughe diff.gz, as it was common in early days in Debian. That makes things harder to check for NMUs and security. Perhaps dpatch is not the best patch system, but it is quite clear where are patches. -- José Carlos García Sogo [EMAIL PROTECTED]