Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi,
Chris Frey wrote (03 Mar 2012 14:50:14 GMT) :
> Stable is what I had handy. I realize this is a work in progress.
I suggest you use a pbuilder sid chroot to build packages
that are supposed to be uploaded into sid at some point.
> There's a large body of work on the opensync side that is not yet
> visible to anyone in Debian. Maybe I can get that into Debian as
> well, but I doubt it will make the Wheezy deadline.
Yeah, see the recent announce on debian-devel (today or yesterday)
about the current poor state of opensync in Debian. Not reassuring.
>> > I've also fixed some lintian errors. The following warnings remain:
>> >> W: opensync0-plugin-barry: new-package-should-close-itp-bug
>> > This can be ignored, I think.
>>
>> Putting two source packages into the same Git repository will be
>> a pain. Let's talk about this other, new source package
>> (opensync0-plugin-barry) later, and keep focused on the barry one to
>> start with. By the way, I think the source package would be better
>> called opensync-plugin-barry; and if it really needs to be a separate
>> source package, Lintian is right, you need to fill an ITP for
>> opensync-plugin-barry, and close it in its debian/changelog.
> I named it opensync0 since that plugin depends on libopensync0, which
> is available in Squeeze.
libopensync0 was a binary library package built from the opensync
source package. Using ABI numbers in such a binary package name is
recommended. But I don't see any reason to use ABI numbers in the name
of this *source* package, unless you really expect to maintain
multiple opensyncN-plugin-barry *source* packages concurrently in
Debian, which can be done, but generally needs to be backed with
solid arguments.
Anyway, the dependency on a package that is not part of Debian
testing/unstable makes this plugin not suitable, as is, for Debian.
Let's postpone the opensync part for now.
> The opensync-plugin-4x plugin depends on libopensync1 which is not
> yet officially released, but does work. That plugin is named
> opensync1-plugin....
I can't find any such package in Debian.
> In order to use both 0.22 opensync and 0.4x on the same system, the
> specific naming was needed.
Can these two versions of opensync be installed concurrently on
a Debian testing/sid system?
> But the entire opensync side of things can be postponed for now,
> at least where Debian is concerned.
Ok.
> The opensync subdirectories do not get built automatically.
Do you confirm you mean that the opensync-plugin/ and
opensync-plugin/debian are part of the orig.tar.gz, shipped in the
source package, but not used to build any binary package?
>> I find it misleading to write "barry (0.18.0-1) unstable" in
>> debian/changelog right now; I think it should only be done at the last
>> minute, once the package is really ready to be uploaded to Debian
>> unstable, which is not presently the case. Until this point is
>> reached, I find it saner to:
>>
>> * either keep UNRELEASED instead of unstable
>> * or manually manage lower-than-release but increasing version
>> numbers (e.g. 0.18.0-1~1, 0.18.0-1~2, etc.)
>> * or use git-dch to get automated lower-than-release but increasing
>> version numbers
> I'm not sure how this is misleading, since if it doesn't exist in
> Debian, then Debian shouldn't care.
I, as the one who's spending time to review your packaging, and
offered to sponsor your packages, do care. I find it useful to be able
to infer, from a given package version number (be it a source or
binary package built from your Git repository, or installed on my
system), if it was a package that was uploaded to Debian or a random
development snapshot. With the versionning scheme you're currently
using, how can we distinguish between a package built from your
current Git repository, and the package (with version 0.18.0-1 as
well) that will hopefully get uploaded into Debian once all this stuff
is sorted out?
> If git-dch can completely eliminate editing the changelog file,
> though, that might be worth looking into.
It does not completely eliminate, but it avoids many of the usual
pitfalls beginners at Debian packaging often fall in.
>> Building in a sid chroot fails for me:
[...]
>> => missing build-deps?
You need to make sure your package actually builds properly in a clean
sid pbuilder chroot. Seriously, this is a prerequisite for any further
review of mine.
> The Desktop GUI currently requires either libopensync0 or libopensync1,
> or both, and is fairly useless without the plugins to go along with it.
> It is tricky to compile the Desktop for both.
Just to confirm I've understood what you mean, do you mean the desktop
GUI binary package should depend on libopensync1exp7, and the source
package should build-depend on whatever opensync -dev package?
> Without opensync plugins, though, we should leave the Desktop out of
> Debian for now. Is there an easy way to make packages optional?
I'm not sure what you mean by "optional". If a given binary package
should not be built, just remove it from debian/control etc.
If you want to keep infrastructure to build a given binary package
outside of Debian, and avoid shipping it into Debian, then I suggest
using a dedicated Git branch for your non-Debian packaging.
> The way I've done it so far is adding debian/ directories in the
> subprojects, as completely separate source trees, like the opensync
> plugins are.
I suggest moving these "completely separate source trees" either into
dedicated Git repositories, to make them really separate.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| Who wants a world in which the guarantee that we shall not
| die of starvation would entail the risk of dying of boredom ?
Reply to: