Re: leechcraft (closes ITP bug, 33 days have passed)
Hi,
>>> qxmpp, Qxt, eiskaltdcpp, miniupnpc, parseUri, lightbox,
>>> hunspell/myspell (and anything else in 3rdparty or third-party dirs)
>>> are either already in Debian or should be packaged separately, you
>>> should not include them in the binary package or tarball.
>> You are really mistaken at this point. Maybe you have read my description
>> inattentive or I have write it not enough clean. So I should explain here...
>>
>> * qxmpp package already exist in Debian. But it is absolutely not suitable for
>> leechcraft. Leechcraft authors have made a lot of patches which are not included
>> in upstream of qxmpp project. Some patches they (upstream) applied but not all.
>> More over qxmpp is the static library. And nobody uses patched version of qxmpp
>> except leechcraft project. So it should not be moved into separate package.
>> * eiskaltdcpp package already exist in Debian. But it is another project with
>> own binaries. Its authors have made special modification for leechcraft project
>> (it also includes a lot of patches). And this modification is now just usual
>> leechcraft plugin. It can't be used separately. So them should not be splitted.
>> * etc...
>>
>> All these files were carefully described in suitable sections of
>> debian/copyright file. And I don't see any reason to break current structure of
>> the package.
>
> I'm sorry, but our policy is very clear on this point. Please refer to
> §4.13 [1] for some more background. While it is not a strict must
> requirement for every case, there are very good reasons to avoid
> embedded code copies whenever possible. I'd consider your case as "when
> possible" which makes it somewhat unlikely to find a sponsor for it as
> is, which would upload your package.
Please read my answers carefully before replying. I have a strong feeling that
you just ignore my arguments. And that you want to throw my work into trash.
Maybe you don't understand that these files are part of the project. They can't
be cut from the project without destruction. Like a brick can't be moved from a
wall without detrimental consequences.
I can repeat my arguments in other words to make sure in common understanding
between us.
* qxmpp is a fork as you wish. It is the internal part of the project. Even if
it is not included in original upstream tarball.
* eiskaltdcpp is internal part of the project. It was produced specially for
leechcraft by original authors.
* miniupnpc is not used. It just present in tarball. Its license can't be cause
of any problems. Plugin will use debian package miniupnpc from the main repo.
> Note, some popular packages aren't part of Debian for this very same
> reason. Think of xbmc for example [2].
Yes I know other examples. It doesn't matter.
> We, as a distribution have to be very careful when embedding libraries
> and third party applications into a package. You can happily do that
> upstream if the respective licenses allow that, but such a package is
> not maintainable in a distribution for the general public. Think of
> security updates, transitions and other updates and we didn't even talk
> about the waste of space yet.
Please don't think that I am stupid or that I don't know basic principles
of distribution of *nix systems.
1) You must agree that we are not talking about any system library.
2) We are talking about _internal_ library in the project. It is used only in
this program and nowhere else. So where is no necessary to maintain it
separately.
3) This library is not simple duplication of original sources from another
library. This is completely another library now.
4) This is completely static library. It can't be updated in programs without
their re-building.
5) Also we are talking about _internal_ plugin in the project. It can't be used
in other way. Only in this program.
And the last argument is that [1] is not strict rules but just recommendations
which allow exceptions.
> That's especially true for you, who are embedding regular packages into
> your binary package which works fine for ... well a lot of reverse
> dependencies. If it does not work for you as is with your upstream
> source, well, I'd expect the problem to be with it rather on your side.
Eh... You have absolutely ignored my description. This is not project fault that
qxmpp upstream don't want integrate all their patches. They had to made a fork.
In conclusion I want note that you shouldn't destroy anything without proposing
possible solutions. Because this is way to nowhere.
So have you any constructive recommendations which can be discussed?..
Finally please answer to my previous questions (from previous messages).
It is important.
In any case thanks for spending your time.
Regards,
Boris
[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469397
Reply to: