Dear Boyuan, On Thu, Sep 08, 2016 at 12:14:53AM +0800, Boyuan Yang wrote: > > 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. The issue is that then we then have multiple copies of the thrift files in Debian: a copy in each source package that needs them, either for regeneration or in debian/missing-sources/. Suppose there is an Evernote protocol change, or some other bug that means the thrift files get updated. If there is one copy of them in Debian, we just update that, and then binNMU all the packages that use it, and we're done. Otherwise, if there are lots of copies, we have to update each package separately. That's significantly more work, and can't be done by just one person, but needs the involvement of the maintainers of all those packages. This is especially relevant if we need to update the thrift files in a Debian stable release: updates to packages in a released version of Debian have to go through a careful vetting procedure, and this means we only have to do that once. That saves a lot of time (and indeed makes it feasible at all). It's possible I've misunderstood the purpose of the thrift files, though -- if there was an Evernote API change, they would have to change and the corresponding language-specific generators re-run, right? > 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? I'm not sure about a package that only contains source code alone, but I can give you an example of one that contains source code plus some other stuff: dh-elpa. If you look in the emacsen-common folder of its source package, you'll find some scripts. Those get copied into every elpa-* binary package (with the package name substituted in). And dh-elpa is added to the elpa-* package's Built-Using field. Before dh-elpa, there was a copy of those emacsen-common scripts in every single Emacs lisp addon package (and in package that have not yet been converted, it's still there, e.g. s-el). That meant that fixing bugs in those scripts or improving/reworking the Emacs Lisp addon packaging policy[1] means updating every single Emacs Lisp addon source package, and re-uploading. Thanks to dh-elpa we can update the scripts in all elpa-* packages just by changing dh-elpa, and rebuilding the elpa-* packages.[2] > > 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. That's fine. > > 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? Take a look at the two overrides in d/rules. You shouldn't need to know anything about Emacs lisp to understand those. [1] https://www.debian.org/doc/packaging-manuals/debian-emacs-policy [2] We can't actually binNMU them because arch:all binNMUs are currently not possible -- but that will be fixed at some point, and it's still easier to rebuild all those elpa-* packages without modification than it is to update their copies of the scripts and then rebuild. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature