Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
2016-09-08 0:52 GMT+08:00 Sean Whitton <spwhitton@spwhitton.name>:
> 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.
Unfortunately things will not be the case, at least not for Evernote thrift
files.
I had some discussions to the current maintainer of QEverCloud about
the possibility of updating thrift IDL files and regenerate again.
https://github.com/d1vanov/QEverCloud/issues/5
He just told me it is not possible, since the generator needs to be
updated. Update in Evernote thrift files will simply leads to FTBFS
without the update in the generator.
> 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?
In this specific case, we also need to notice the slow evolvement of
Evernote Cloud API (>= 3 years, longer than Debian stable release cycle.
Take a look at Evernote official SDK)
and the backward compatibility of the API. Not updating API will not cause
problems, and it is the author of program (i.e., nixnote2 author) who has
the responsibility to update the level of API itself uses. Even if the Evernote
API is updated according to the new thrift files by packagers, the added methods
will not be utilized until the program author decide to switch to the
new API, and
the changed/removed methods may lead to FTBFS.
>> 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]
Unfortunately Evernote thrift files are neither lisp nor shared libraries.
I understand the advantage that common files get updated separately and
a rebuild solves the rest of the problem, but this is not the current case.
>> 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.
Are we talking about the same package? :p
I ran `apt-get source ebib' and got ebib v4.5.2. The debian/rules is
nothing more
than one line of `dh $@ --parallel --with elpa'.
Sincerely,
Boyuan Yang
Reply to: