Re: RFS: sqlbuddy
Medhamsh, 2012-01-23 18:31+0100 (gmane.linux.debian.devel.webapps):
> Ya. I have a VCS repo at gitorious.org. I am a beginner in packaging
> and dont know the proper way of maintaining packages under VCS. Would
> be happy if someone shows some best practices. Eventually I will adapt
> once I have more than 5-6 packages to maintain.
I think the most common practice for packaging with Git is to store all
the package directory, containing the original sources and the debian/
directory. Have an “upstream” branch tracking upstream releases, from
the released tarballs or possibly from the upstream version control as
long as it matches the tarball content. Tag upstream releases as
“upstream/version”. Have a “master” branch, derived from the “upstream”
one, with your Debian work on it. Tag Debian revisions as
“debian/version-revision” when they are uploaded to Debian (to the
Debian archive I mean, not to mentors). If you have patches against the
upstream version, store your work under Git with patches unapplied.
And finally, indicate the URLs of your VCS in the Vcs-* control fields.
>> debian/rules: I am curious, is there a reason why you did not use
>> catchall-style shore dh7 rules?
>
> Since this is my first package, I thought I would learn and remember better
> if I write them all and also catchall style appeared magical and advanced to
> me. May be I have to adapt it soon?
Personally, I think that should be your choice. I use dh7 short style
but I have nothing against other styles.
>> debian/watch: The upstream release practice prevents you to have a watch
>> file indeed, I think you should ask them if they could publish versionned
>> tarballs.
>
> I was really struck here. Tried several times with all regexps but couldn't
> succeed. I could find out a github page for the project.
>
> https://github.com/calvinlough/sqlbuddy
>
> Can I use http://githubredir.debian.net/ for generating the watch file.
I think you can, since you need repacking the upstream ZIP archives
anyway, so you could as well use some Github-generated tarballs. As long
as their content match the upstream released ZIP archives.
>> There is also the empty /usr/share/sqlbuddy/exports/ which is detected
>> by Lintian. I guess that is intentional, but if this is a directory where
>> database dumps will be placed, then it is at a wrong place, and it should
>> be under /var instead, with the appropriate configuration, patch or
>> symlink.
>
> Are there any additional flags while using lintian? Because, many of the
> errors were not detected by lintian in my computer. I came to know them
> only when I uploaded to the mentors.
Yes, Lintian has several levels of information, and that one was
informative, in other words not a real problem by itself. Some options
you can try: --color, --display-experimental, --info, --display-info,
--pedantic.
> And one more doubt. Can I just make the changes you suggested and re-upload
> the package to the mentors with the same package version?
The version only has to be changed if there are regular users already
using the current one. Since mentors is not a common binary repository,
that is not the case, so you can use the same version number.
--
,--.
: /` ) Tanguy Ortolo <xmpp:tanguy@ortolo.eu> <irc://irc.oftc.net/Tanguy>
| `-' Debian Developer
\_
Reply to: