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

Re: Looking for mentor to package dolibarr erp/crm - ITP 634783

Le 30/07/2011 20:38, Arno Töll a écrit :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Laurent,

On 30.07.2011 19:32, Laurent Destailleur (eldy) wrote:


Now i use the dpkg-buildpackage to generate .dsc, source and binary
package at once.

Yes. This sounds much better. Thanks for doing this.


This seems to be fixed now.

Cool.


I was aware of documentation that recommand usage of dpkg-buildpackage
or debuild but I found also other documentation found on debian web site
that was speaking about using dpgk -b and dpkg-source. So i made a
choice, simply the wrong one. I try to find it again again on net but
fails. Sorry if this has wasted a part of your time.

Please note, these are orthogonal approaches. "dpkg -b" is not meant to
produce useful binary packages, but just to produce a package (the
physical package.deb archive that is) out of stuff you prepared by other
means. dpkg-buildpackage aggregates all those steps.


I removed this dependency. I added it because i found current package
using it and i wanted to do "like others". Not always the good way to
work :-)

Which package is having firefox as dependency for a _web_ service?
That's serious policy violating bug. Please have a look to the Debian
policy which clearly explains when to declare which dependencies.
I used google some days ago to find examples but I can't remember which package it was. I can remember it was a ubuntu package, but I supposed it's same as most of them comes from debian. If i find it again, and if this is into control file of debian source, I promise to report a bug. 
Moreover please note, I did not point out all issues with it. I can
remember, there were some more problems with your control file.
I imagine you speak about dependency with apache (you speak about that at bottom of email) ? I will work soon to have package working even with lighttpd or other web server with php. 
I let know on mentor ML (may be dev ML is more appropriate) ?


I read several times debian policies and i don't think I misunderstand
what is a debian package.
So let me explain my pooint of view: Dolibarr contains a "web install
wizard" that is required (for the moment) to setup Dolibarr completely.
The reason is we think debian package system can't do everything, or at
least can't do sophisticated tasks, moreover when it needs a lot of
conditionnal or crossed interactions with users or need sophisticated
error management on databases.

Please note, I don't argue against Dolibarr itself. It may be useful (or
not - I don't know). I argued about the location /where/ you install it.
The file hierarchy standard cleary states which files are allowed to be
installed where.

Moreover the policy forbids embedded code copies of libraries. Those
have to be packaged separately. Have a look to §4.13 of the Debian policy.
But what about if such copies are no more original copies and was used as source to be modified to build other libraries now specific to software. All opensource software contains some part of other code that was cut and paste from other licence compatible opensource software. That's a force of opensource. Do we have to build packages each time some code was extracted from other project ? Moreover some of thoses code come from project that does not exists anymore (ie artichow libraries). So code is now only maintained by the dolibarr team only, as part of dolibarr itself. Do we really have to build a secondary package for code that is used and will ever been used by dolibarr only (because contains change specific to Dolibarr) ? PHP Libraries that are used as is and "not modified" by Dolibarr are already removed from last package I provide (ie php-mime). 
The postinst - postrm
actually initialize the first part of config files into /etc/dolibarr,
the wizard ask missing things and do the rest . For example, the wizard
can detect database table lost, problems into permissions, duplicate
instances, migration process from version x to y that failed making data
corrupted, etc... and fix all of this. And there is a lot of other
things, like tracking installs date into software itself that is a
feature required for some business usage or country needs, etc...

Fair enough, but please notice it is not allowed by Debian policy to
touch other package's files and/or name space and/or domain.
Sure. Not a problem, Dolibarr package does not touch any file of any other package. 


  Therefore
you have to be _REALLY_ careful when you try to install data base
schemes in a postinst script.
Yes, that why this part is done by an online wizard. Because all the care we need can't be put into a postinst script. We spent several years to have an install wizard able to install or upgrades thousands of tables and data whatever is start situation. 
...


/etc/apache2/conf.d, or removing data or database when package is
purged. And the wizard do the rest.

Another note: Debian is meant as /universal/ operating system. We have,
I think, around 10 web servers in Debian and we don't require our users
to use either one. Your stuff could perfectly run fine on every CGI
capable webserver, e.g. nginx, Lighttpd and many more.



This is, why your dependency to Apache is wrong by the way. We have
virtual packages which are for your requirements.

Right.
I will work on this now.
I will have a look at this and will fix this. I will take example on phpMyAdmin that has following depends: 
libapache2-mod-php5 | php5-cgi | php5-fpm | php5
and recommand ;
apache2 | lighttpd | httpd


I try
here to explain why we think removing the wizard is not a good idea. It
is technically possible, but this will means that debian package will be
less featurefull and less secure for a critical usage than other
platforms, and we want to avoid this.


I didn't say you should remove it. I said, Debian scripts must be
idempotent. That means they can

* be interrupted
* be called again
* be called on every possible circumstances (e.g. with a database server
installed but not running, or not fully configured yet ...)
* not called at all

and any combination thereof. This is why you have to make /really/ sure
your stuff is side effect free and  your installer clearly is.
Yes, that's completely the goal of wizard. And the wizard match all this requirement. We built it for this: 
* be interrupted
* be called again
* be called on every circumstances (server on or not, not fully configured, etc...) 
* not called at all (called only when required)
And I can add more :
* Must work and block when user make wrong things (for example installing a wrong version of software on a wrong version of database) or 
ask to migrate
* Can report understandable errors to make a helper to diagnose remotely from log files 
* Can't be used without admin permissions
* and a lot of more things to avoid errors, data lost we experienced during past years or allow data recovery.
We spent several years to develop it to be sure it works in all situation. And this goal is achieved since now 2 or three years. 


Does this usage is really not debian compliant ?

See above. You can't safely assume the database is running at all. Or
the user of it is using Apache. Or whatever does not belong to your
package and desired applicable use of your package.

If database is off, wizard will manage this.

See, in Debian we try to make sure, our setups work for _all_ users of
the package and for _all_ possible alternatives.


But you rule. So tell me if this is absolutely necessary to remove our
wizard (all files into /install directory will be removed and replaced
into more powerfull database create script with interactivity managed by
debconf).

I don't rule at all, all I'm doing is to /sugggest/ you things and show
you problems. You can obey them or not, but its more likely for you to
find a sponsor, if you obey packaging rules.
Those are not to annoy you, those are to make sure your package works
for your users. Yes, we're pedantic, but we do this on behalf of our
users which do expect a stable system.
I understand. This does not annoy me, this help me to offer the better solution for debian that is also the better for users that ask us for debian pakages. I am also pedantic with dolibarr modules contributor, so i am at the wrong place to understand ! Don't worry. I will take time that is necessary, but i will modify according to your advices until things are enough good for every body. 

I will make another post when depencies will be fixed.

So I hope my explanation will make you understand my philosophy. But you
decide, so I'm waiting for your feedback.

See, its perfectly fine for your private use to do such things. Its a
totally different thing to package for everyone. This is not to offend
you, and this is not to blame your for not obeying our policies.


or to match
Dolibarr security rules (for example to match some Dolibarr option to
have default mask usage of written files being 600 instead of 660 for
paranoiac users but there is tons of other examples).

This is exactly the same reason why we don't want to introduce new
packages with embedded code copies. We have a security team which needs
to track about vulnerabilities in packages, and, by case, fix them by a
new upload to Debian stable.

How should they know, a security problem in a library you are embedding
also affects you? Moreover: Why should they fix more than one package
for the same vulnerability, just because the maintainer makes use of an
embedded code copy?

this is /not/ about licensing. Pretending your libraries are all
compatible to the GPL, its fine to make use of them.


Those README files are not documentation files but files to tell what is
the content of directory. This is to help someone to analyze Dolibarr
tree. Do we have to remove them ?

Well, that's the supposed document root, isn't it? Does it sound like a
serious, clean package to you, if you install docs to the document root,
instead of the location the FHS suggest (/usr/share/doc/)?


Documentation is correctly installed into /usr/share/doc/dolibarr.
What i tell, is that documentation is inside /usr/share/doc/dolibarr but there is also README files that are no documentation files into directory with a one line content to tell "This directory contains files related to system tasks xxx". Well, to solve this, because they are useless for everyone except developer, i think I can remove them. 
For translation, we also can't removed them for the following reason:

Its not about to remove them, but to package them approrpriate.
Depending on your translation's size it would be even useful to package
them separately. /Anyway/ they should be centralized, not somewhere
hidden in your tree.
Package is around 20 Mb compressed , and files to generate documents into customers language are 200 Ko compressed. And user need all languages to start to work, because they are used not only for user translation but for translation of data manipulated by software with no way to know which language will be required, as it does not depends of software usage but on external events (a phone call or a web visitor from anoher country). 
Files are however centralized into langs directory.



As a last note: Please don't address me directly. Please use the mailing
list instead. We do all of our work public, and other people might want
to join our discussion. Moreover I may or may not have time for you.

Right.
I will be more carefull when making "reply" on message now.
- -- with kind regards, 
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJONE+aAAoJEMcrUe6dgPNtFUMP/R9M4L7qf63U9f3pumlLbB0E
32d4UMiNTekToiLd2AkA1hkjRlxGZcLjmAiiPxZ/pk/q+g7zvhot6FnEp4mJrkUu
zYk9f2bKr+Qqkt5uTpv2tlsuJA2PgOQ3otrD+muQB96RZV/P3LZ2pjptVJNwyVTl
NYTEh8s0F48xrSJP2+802xwFOT7rKdwGXlUCmTp7Hvr07p4fp/zfw2MF0KpRcGqu
rtqXkEqYMj1ZTbtCU7VhnOvF8U69FMZelj7c3y7DUnM0OK8WqdINBTQMPKwXCvnh
hMMzQ/E6TwknDYmD+cRY83T9kicWDGG8/Mp8ufiGXV9fXiiITAMWshyn/fqVyzuh
3ocG6mYm/MmU42YlVOT+nZjFJkxsQlXTjFHiZqbWVIUOHmyfCbsLBeWRTsfhuJh1
4bq86/eB4qv7cwQ18YUfGvHxrY07ZsUaTFTwioN5TSCEFUaOqfBZX5ngavZ4tV13
5t49YVW0Evy+6XwK+0zey+BAdoBb9EDQ3C1RI1nW2Q6ILuG3F3tOvg5Cbt9BAWGy
NLSwiNSH9jiBEPY3aJ3BFPKtwI9JXpv2HIG8Sflpyq2GdA9YsG8DEo/lf4E24Ghb
Li5Puv0x6PYAw2AXsiHRIuNDhXbNgRgvJuZNZZ9ciXV7FaUbAZyiTfkeEdFjG88I
xdyYx5a1ANmD8cBYDZda
=LW8v
-----END PGP SIGNATURE-----



--
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: eldy@destailleur.fr
Web: http://www.destailleur.fr

Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: contact@destailleur.fr
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: contact@destailleur.fr
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
Reply to: