Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Hi Sean,
2016-09-11 5:46 GMT+08:00 Sean Whitton <spwhitton@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
Reply to: