Bug#657076: Updating and maintaining barry in Debian / Ubuntu
On Sun, Mar 04, 2012 at 01:33:14PM +0100, intrigeri wrote:
> > 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.
I already do maintain two separate opensync plugin source trees.
They are both included in Barry, under the opensync-plugin and
opensync-plugin-0.4x directories. The opensync API changed significantly
between 0.2x and 0.3x, hence the need for two plugin sources.
> > 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.
The 0.3x version of opensync was called libopensync1exp7 in Debian, but
may have been removed by now. In my own binary packaging for 0.3x
I moved to calling the binary package libopensync1, since that matched
the pkgconfig name to some degree.
> > 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?
Yes. I'd have to double check the -dev packages, but I worked specifically
to make it possible to install both at the same time.
> > 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?
Yes. There are opensync-plugin/debian and opensync-plugin-0.4x/debian
that are both built separately, or as make targets from the root
debian/rules file.
The main subprojects (the plugins, the gui/, and the desktop/ directories)
have their own configure scripts and can be used standalone if desired,
although they all depend on the Barry library.
> >> 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?
I misunderstood who you were referring to. I can see how you would care,
and it's not my intention to make it confusing.
But once 0.18.0-1 is uploaded to Debian, my git repo should not say
0.18.0-1 anymore. My git repo contains the version number of the next
release, so I can use it in the same state that it will be released in,
and fix issues that arise. As soon as the release is made, the version
gets bumped again.
I would assume that if I'm doing the maintainer work, I'd have some say
over when an upload happens, and could therefore update the version numbers
appropriately.
> > 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?
Well, libopensync1exp7 should not be used at all. It is too old. The
latest opensync 0.3x devel tree in git should be used instead, if we're
going the devel tree route.
To clarify, the Desktop GUI which is found in Barry is designed to use
either opensync 0.2x or 0.3x, or both. It uses dlopen to load the library
manually, so technically opensync can be uninstalled completely and
the Desktop will still run, just not sync. But in order to build, you
need the headers, etc. This is a ./configure compile issue,
and I haven't made it work The Debian Way(TM) yet. It only works in my
binary-meta system.
But since opensync 0.3x probably won't exist in Debian for now, you only
need libopensync0-dev to build the Desktop.
> > 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.
Barry is much like the linux kernel source tree: everything is included,
almost like modules, and everything gets built during development, in order
to keep all code in lock step. This is done on purpose, in order to
encourage developers to build and test the whole thing. But the subprojects
are separate enough that they can be extracted if necessary.
So while Barry won't be splitting up, a script could be added to create
separate tarballs for you, if that makes it easier.
I have no guarantee that Barry (let alone opensync) will make it into
Debian. So I really hesitate ripping up Barry's existing, and working,
packaging for Debian, when I'll need it to release binary packages soon
anyway.
If the Desktop cannot be included, I can make it optional, just like the
opensync plugins are. That's not a problem. I was just hoping Debian
had encountered this problem before, and had a nice solution.
As for the rest of the feedback, it will take time. I'll let you know
when it's ready for more review.
Thanks,
- Chris
Reply to: