Ingo,
thank you for your comment. For the most part I had the impression you
were in an aggressive, not in a contructive, results-oriented mode. At
first I thought I would skip to answer you, but then I felt I should
give you the benefit of the doubt that in the end you are interested in
improving and sharing and not in "being right" or "winning an argument"
or anything like that.
1) the source is not published (this is actually a GPL violation)
[...]
How would we have made it into Debian if we wouldn't do that?
I thought it was clear that we are talking about
https://download.jitsi.org/jitsi/debian/jitsi_2.5-latest_amd64.deb for
example and not
http://ftp.us.debian.org/debian/pool/main/j/jitsi/jitsi_2.4.4997-1_all.deb.
Availability of the source of the former is not immediately obvious as
I thought I had explained.
Well. I'm not familiar with how a "usual" download directory should look
like.
A usual download directory for a debian binary package generally has the
original tarball, the debian tarball (packaging information) and a dsc
file (and possibly others). These files are not published anywhere for
the jisti-supplied debs, but I believe you create them from the source
snapshots you do provide and throw them away after the build. That's
unusual, seems wasteful and lends itself to misunderstandings of the
kind we had but I guess it would be a slight stretch to call it a
GPL-violation, so I backtracked on that.
Our download page provides pre-built packages for all supported
platforms and source code snapshots. This snapshot is probably not what you
want because it contains the dependent libraries as binaries.
Yes, all distros will discourage embedded code copies.
Shipping all your libs might make sense to make sure things are working
but is not something you can recommend to someone who takes the proper
and secure functioning of his computer seriously. It makes sense for
jitsi as a project, I understand that. For me as a user, it wouldn't be
something I like.
These are included because it would be next to impossible for a bypasser to
compile 20+ referenced projects (all with their own dependencies)
This is the distros' job, most importantly that of the packager
supplying accurate build-time information. Building jitsi on Debian
usually requires only one command to download the source (including
packaging information) and one more to build it in a clean chroot
environment. All lib dev files, etc. are taken care of. Your setup
completely breaks this for the snapshots.
http://lists.jitsi.org/pipermail/dev/2014-January/019700.html
Yes, it would be good to have that information more prominently
available. Still, this looks awfully complicated. More than it has to
be IMVHO.
BTW, I just *did* the work of backporting jitsi to wheezy-backports.
The branch I published should compile fine in wheezy, precise is even older.
Those who don't want to use our repo:
fine, use that of the distro (and please excuse my sarcasm, enjoy Ubuntu bug
894302).
Excuse me, but is that sarcasm really necessary? Are you absolutely
sure that your code has LESS bugs than the stuff in Ubuntu? With LOTS
more eyeballs on what is in Debian and Ubuntu? And even if it was,
would I as a user REALLY want to spend my time auditing that this is in
fact true (assuming that I would be able to, which I'm not)? And would
I REALLY want to repeat this process after every one of your releases?
And keep up-to-date with security alerts, etc.?
For me, the answer is clear. Using a distro comes at a price, but it's
WAY lower than the alternatives.
The reason why the Debian files are not in the root directory is simple: we
support Windows, Mac and Linux. Placing a Debian directory (or rpm or
whatever) would clutter the directory tree.
I strongly suggest you use separate upstream code and packaging code
branches. Then the problem simply goes away. It seems you already use
different repos, not even branches in the same repo, to compile your
bundle every time. I'd think this would be a lot cleaner, easier to
maintain and wouldn't break the build-tools in Debian and probably other
distros.
In a nutshell, I believe other bypassers could fall into the same trap
as me and if like me they are unconfortable to install binaries they
cannot reproduce from source then my initial argument remains valid IMO.
I've seen far worse open source projects... but I might be biased.
Whether jitsi is a good project or not is not the point.
I've not even looked or tried to and I don't want to - and that is the
point. Why repeat the work that somebody else is much more qualified to
do? My policy is to usually not install software that hasn't passed
Debian muster.
And once more, coding and packaging skills are not the same and there
are VERY few people who understand both well.
I've taken care of some other bugs and we'd happily include patches into our
master tree. To do that however, we need them be created and submitted from
someone who signed our contributor agreement (http://bluejimp.com/bca.pdf).
I'm willing to put my efforts under GPL. That's good enough to do
packaging work for Debian.
Best regards
Rolf
···
On 08.03.2014 22:06, Ingo Bauersachs wrote:
On 04.03.2014 17:48, Ingo Bauersachs wrote: