Hi Sean, 2016-09-11 5:46 GMT+08:00 Sean Whitton <spwhit...@spwhitton.name>: > In that GitHub thread, there is mention of a parsing tool called > 'lemon'. Dmitry suggests packaging that separately, but you say it's > not necessary. Could you explain why? Where can I find out about that > tool? >
"apt install lemon" will find the tool. It is part of sqlite3. > - status of lemon parser currently unclear This is fixed in the RFS of qevercloud before already. Of course we are using the lemon parser from Debian. The bundled source code of lemon is discarded in the source package. Sorry I didn't update the situation on that Github thread, which is a little bit outdated. > If an Evernote API change would cause qevercloud to become useless, it > would make sense to package the Thrift IDL files separately. When those > were updated, qevercloud would FTBFS, and that would be a good thing > because it would alert us that the package was broken. > > However, as you say, it turns out that the Evernote API is backwards > compatible. Even if qevercloud lagged behind other Debian packages > using the Thrift IDL, we would want to keep qevercloud in Debian > alongside those other packages, becauae QEverCloud would remain useful. > So, in conclusion, it's okay to have multiple copies of the Thrift IDL > files in the archive. I would like to return to the very beginning of the problem: QEverCloud upstream source code contains some generated cpp codes but did not provide the direct way to regenerate them *within the source code*. (Dmitry keeps the custom generator together with instructions of regeneration inside another public Git repository, and the thrift IDL files needed for regeneration is in another public Git repository kept by Evernote.) Since Debian Policy (or at least ftp-master) requires at least the possibility to regenerate all generated files (I believe they were thinking about files generated by autoconf/automake), so I repacked qevercloud and included qevercloudgenerator and evernote-thrift files inside qevercloud source repository. So far everthing is fine, but this is the point opinions diverge. You suggested the separate packaging of qevercloudgenerator, but now we seems to agree that since it is not useful for anything other than building qevercloud, it should not be packaged separately. Now the problem is focused on the separation of evernote-thrift files. I believe you suggested packaging thrift files alone, since the separated package can be used by other packages (most likely as a Build-Depend?), and to deal with the FTBFS of qevercloud after the version bump of evernote-thrift, we can include multiple copies. Did you suggest the coexistence of multiple versions of evernote-thrift in the Debian repository, for example, "evernote-thrift-1-25" and "evernote-thrift-1-28"? Or if I misunderstood, it is just one package "evernote-thrift" but provides different versions of files inside one binary package (e.g., /usr/share/evernote/thrift/1.25/foobar and /usr/share/evernote/thrift/1.28/foobar)? Personally I am against the separated package of evernote-thrift, and the main reason is that it is not useful; thrift files are technically used by no one other than evernote people; developers are encouraged/guided to use official Evernote SDK released by evernote, which is already a generated project from the thrift files; no one else is parsing thrift files by him/herself. There was a reason of FTBFS, but the coexistence of different versions can solve this problem. But don't forget that we only wanted to deal with the policy violation. I may package evernote-thrift files if you insist, but please tell me your preference on the coexistence of multiple version (as stated above). > Are you sure? There has never been ebib version 4.5.2. The version I > meant was 2.6.3-1 in unstable. Try `debcheckout ebib`. OK I got the correct version now (2.5.4 though, I am using testing). It is really weird, what was I looking at before? :-| > * * * > > To summarise our discussion so far: > > - qevercloudgenerator should not be packaged separately because it is > not useful for anything other than building qevercloud. Sure. > > - the source package containing qevercloudgenerator should embed a copy > of the latest Thrift IDL that it is compatible with > Yes. Personally I think the embedded copy has no special functions but to make sure the regeneration really works and makes ftp-master people and those who examines this package against Debian Policy happy. > - ideally qevercloudgenerator will be run during the qevercloud package > build, though a promise that it can be run is sufficient for the > ftpmasters Yes, and in current building instruction we are choosing to run the regeneration. After all this is a really interesting problem, a combination of automake/autoconf generated files and the versioning/packaging problem of shared libraries. I have heard that in the (unreleased) debhelper compat level 10 the regeneration of autotools files is the default behaviour, which indicates the changes of people's thoughts. Sincerely, Boyuan Yang