Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Hello,
2016-09-07 23:15 GMT+08:00 Sean Whitton <spwhitton@spwhitton.name>:
> control: owner -1 !
> control: tag -1 +moreinfo
>
> Dear Boyuan,
>
> Thanks for this! Before I do a proper review let's talk about the
> source code/repacking situation.
>
> Are there/could there be other libraries that use code generated from
> the Evernote thrift files? For example, bindings for another language
> (python, haskell, perl)? If so, the Evernote thrift files should be in
> their own package, and this package can build-depend on it.
If you are talking about bindings in other languages (python / haskell
/ perl /...)
for *Evernote Cloud API*, then yes such projects do exist. For example,
https://github.com/evernote/evernote-sdk-python and
https://github.com/evernote/evernote-sdk-python3 and
https://github.com/evernote/evernote-sdk-perl and
https://github.com/evernote/evernote-sdk-csharp and
https://github.com/evernote/evernote-sdk-cpp .
Note that even Evernote developers does not use thrift code directly.
All files are
generated with some third-party generator. The motivation is clear:
for interpreted languages (perl/python/...), parsing thrift
description files in runtime
is too time consuming and impossible. And for compiled languages (C/C++/C#/...),
OK, they just don't bother with the regeneration process. It is a
one-shot process,
the generated c/cpp/c# source codes are still clear and readable, ready to be
embedded into other projects or made into shared library. Packaging separately
is useless to other people.
Thrift files should be regarded as language-independent source code; It does
not make sense for one package to Build-Depend to another package which
only contains some source code. Those codes should be part of its own
source code.
Is there really any previous example in Debian, that one package *should* and
*do* Build-Depend on another *binary* package that only contains some
description files or source codes?
> That would clean things up a bit, but it wouldn't help with
> QEverCloudGenerator -- I guess that no packages other than qevercloud
> itself will use that, right? If it would be easier for you to maintain,
> you could put QEverCloudGenerator in its own package and build-depend on
> it, but that's your choice.
That would make things even more complicated and add another barely useless
binary package into Debian, so I am not intended to pack QEverCloudGenerator
separately.
> It looks like you are have removed the files you are going to regenerate
> from the upstream tarball. That's okay, but you don't have to do it --
> you can just delete them before you regenerate them/just overwrite
> them. See the ebib source package for a very simple example of
> regenerating a file without removing it from the upstream tarball.
I checked ebib and find that I know nothing about emacs lisp and its debhelper.
Where did it remove any file?
What I do know is that I can override dh_clean and delete some files
sooner or later.
Overwriting seems reasonable, too.
> Let me know what you think of these suggestions.
Basically I just don't want to generate more binary packages. The current source
structure is acceptable to me, and the only problem is to decide the proper way
to regenerate source code and build the library. I may choose either to hack the
debian/rules file or to patch cmake instructions. The current implementation is
to hack debian/rules.
Sincerely,
Boyuan Yang
Reply to: