[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About openmeca package

Hello Anton, Hello Leopold,
Thank you for your help. I miss the debian policy about embedded copy of codes. 
It's clear that my package does not respect this rule.

Following this discussion, here is the plan :

1- push out boost from the openmeca package. It's technically easy.
Therefore, if users notify some bugs about backward compatibility, I will fix this issue as upstream author.
2- push out chronoengine library from openmeca and package chronoengine for debian. I plan to package only the C++ core module of chronoengine to minimize technical and copyright problems. As Leopold said, It induces to push out some part of the chronoengine code that embeds itself some source codes already packaged by debian (the bullet library [1]). 

What do you think about this plan ?
The second part will be hard for me, I will probably need some help from the debian community. 

[1]: http://bulletphysics.org/wordpress/

Le 2017-04-26 19:18, Anton Gladky a écrit :

Hi Damien,

first of all thanks for trying to put Openmeca into the Debian.
Very appreciate!

But I would completely agree with Leopold's opinion regarding
the correct way of packaging.

We in Debian are trying to keep the high quality of packages, which
are uploading into the archive. And keeping the convenience copies
of other packages is generally forbidden by Debian Policy [1], [2].

There are some rare exceptions, where technically impossible to
use the packaged versions of packages, but your case of keeping
backward compatibility of "save-files" can unlikely be used for
keeping boost/serialization in the code.

Boost/serialization broken backward compatibility is known "feature".
So this problem should be solved generally on upstream level of
Openmeca if it is really an issue for users.

Pay attention. If your users are all using only "Debian stable" with
the stable Boost-version, this problem should not occur. In testing
we do have of course several Boost version during the whole
development cycle.

Best regards
[1] https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles 
[2] https://wiki.debian.org/EmbeddedCodeCopies

Anton


2017-04-26 10:19 GMT+02:00 dada <dada@yakuru.fr>:

Hello Leopold,
Thank you for your answer !
I am agree with you... therefore I want to explain why I made this "bad 
choice".
I have a long experience with the Boost serialization lib and I experienced 
A LOT of troubles
due to the non-backward compatibility of this library. The results is that 
users can't share
freely their files between them. I was tired to manage this problem, so I 
decide to keep a frozen version
of boost serialization inside openmeca.
If the current version of the boost serialization fix this problem... No 
problem ! I will enjoy
to keep this lib outside of openmeca. But it will be not possible to
guarantee the backward compatibility
between openmeca version that uses different version of the boost
serialization lib.
Now let's talk about ChronoEngine. OpenMeca is a old project and I use one 
of the first free version
of ChronoEngine (in 2013). At that time, the compilation was managed by 
MS-Visual-Studio project and it was
a nightmare to compile it under GNU/Linux and I promise me to never do it 
again :),
When I read your mail, I break my promise and I try again. Now, chronoengine 
use CMake and apparently, the compilation
is quiet simple.... but I suspect that the full compilation (with all 
chronoengine features) will not be trivial.

To be honest, I spent a lot of time in trying to debianize openmeca.
I will try to do something with chronoengine but, depending on the
complexity of this task,
I am not sure that I have the time to do that.

Best regards, Damien.




Le 2017-04-26 08:48, Leopold Palomo-Avellaneda a écrit :


Hi,
I have read a bit about the openmeca package. I'm sorry, but IMHO the 
package is
not well done from the beginning. Let me explain my opinion because I 
would not
be destructive.

openmeca source has three folders:

* ChronoEngine
* OpenMeca
* Serialization

Your package should be just OpenMeca. Why?
* ChronoEngine should be a single package. It's a project, AFAIK you are 
not
upstream (PROJECTCHRONO , https://github.com/projectchrono/chrono).
This project
deserves a single package. I think that it wouldn't be easy. It use
several code
from bullet (gimpact, and should be dropped)
* Serialization. It's Boost and we have it in Debian. I think that you 
cannot
put this code because it violates some policy to repeat it. And, looking 
the
sources, in a fist quick look, they are almost equal than my boost
serialization
folder from Jessie.

So, my recommendation:
- To package ChronoEngine, patching the needed code to use the standard 
installation of bullet. Work with upstream about it. I think that
they will be open.
- Drop from your code all the Serialization folder and use the standard 
installation of Boost

- Package "just" Openmeca.

Best regards,

Leopold
Reply to: