Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Hi,
Chris Frey wrote (04 Mar 2012 13:59:49 GMT) :
>> 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.
This does not answer the "how can we distinguish..." problem, and will
therefore make things harder for reviewers and sponsors, who will lack
any kind of version numbering to distinguish between package snapshots
you show them, but well, in the end you decide.
> 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.
Sure.
*You* prepare the packages, so *you* decide when it should
get uploaded :)
> 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.
Ok. Fixing this FTBFS is top-priority as far as Debian is concerned.
If it ain't buildin', then we can't ship it.
> 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.
Thanks for clarifying.
> So while Barry won't be splitting up, a script could be added to create
> separate tarballs for you, if that makes it easier.
Personally, I won't have any use for such tarballs. As long as you
throw sane source packages at me, I'm happy.
Sorry if I've been unclear, I'm not pushing towards artificially
splitting. I don't think such source package splitting should be
decided merely as a way to answer the initial question, that is "how
do you make packages build optionally". There are many other much more
valid reasons to split, or not to split.
At some point, *you* have to make a decision about which ones of these
subprojects need to get its own source package, or not. You answered
"yes" in practice to this question for the opensync plugin. Fine with
me. But please, don't artificially move $APP into a dedicated source
package only to make its build optional right now. I understand this
is a cheap short-term solution, but splitting has serious long-term
costs, such as making it harder to upgrade the splitted bits in lock
step later.
Maybe just create a branch dedicated for Debian, that removes these
package from debian/control, and that's all?
> 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.
Fair enough. Barry making it into Debian or not now mostly depends on
you, though :)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| So what?
Reply to: