How do we handle these bugs in packaging for one particular architecture?
Do we replace the package silently ? Do we have different version numbers for different packages? Do we make a bug fixing release for all architectures, even if nothing changes in some?
Best
Michel
-------- Original Message -------- Subject: r2081 - dynare_v4/debian Date: Wed, 17 Sep 2008 18:02:33 +0200 From: sebastien@pythie.cepremap.cnrs.fr To: subversion_users@cepremap.cnrs.fr
Author: sebastien Date: 2008-09-17 18:02:33 +0200 (Wed, 17 Sep 2008) New Revision: 2081
Modified: dynare_v4/debian/dynare.install Log: trunk debian/ubuntu packaging: added missing matlab/distributions/ and matlab/distributions/toolbox/ directories
Modified: dynare_v4/debian/dynare.install =================================================================== --- dynare_v4/debian/dynare.install 2008-09-17 16:00:41 UTC (rev 2080) +++ dynare_v4/debian/dynare.install 2008-09-17 16:02:33 UTC (rev 2081) @@ -1,7 +1,9 @@ -matlab/*.m /usr/lib/dynare/matlab -matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv -matlab/qz/*.m /usr/lib/dynare/matlab/qz -matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker -mex/octave/*.mex /usr/lib/dynare/mex/octave -mex/octave/rcond.m /usr/lib/dynare/mex/octave -preprocessor/dynare_m /usr/lib/dynare/matlab +matlab/*.m /usr/lib/dynare/matlab +matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv +matlab/qz/*.m /usr/lib/dynare/matlab/qz +matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker +matlab/distributions/*.m /usr/lib/dynare/matlab/distributions +matlab/distributions/toolbox/*.m /usr/lib/dynare/matlab/distributions/toolbox +mex/octave/*.mex /usr/lib/dynare/mex/octave +mex/octave/rcond.m /usr/lib/dynare/mex/octave +preprocessor/dynare_m /usr/lib/dynare/matlab
For Debian/Ubuntu, it is necessary to bump the version number (for example 4.0.0-1), otherwise the new package will not overwrite the old one for users who have already installed the buggy version.
This particular bug makes the package quite unusable on Matlab without the statistics toolbox (but not on Octave), at least for estimation, since all distribution related functions are lacking. I fixed it manually in the new ubuntu/amd64 package that I have just uploaded. For other archs, we can either recompile the packages by upgrading the number to 4.0.0-1, or wait till 4.0.1. What's your opinion?
Best
Sébastien
Le mercredi 17 septembre 2008 à 18:07 +0200, Michel Juillard a écrit :
How do we handle these bugs in packaging for one particular architecture?
Do we replace the package silently ? Do we have different version numbers for different packages? Do we make a bug fixing release for all architectures, even if nothing changes in some?
Best
Michel
-------- Original Message -------- Subject: r2081 - dynare_v4/debian Date: Wed, 17 Sep 2008 18:02:33 +0200 From: sebastien@pythie.cepremap.cnrs.fr To: subversion_users@cepremap.cnrs.fr
Author: sebastien Date: 2008-09-17 18:02:33 +0200 (Wed, 17 Sep 2008) New Revision: 2081
Modified: dynare_v4/debian/dynare.install Log: trunk debian/ubuntu packaging: added missing matlab/distributions/ and matlab/distributions/toolbox/ directories
Modified: dynare_v4/debian/dynare.install
--- dynare_v4/debian/dynare.install 2008-09-17 16:00:41 UTC (rev 2080) +++ dynare_v4/debian/dynare.install 2008-09-17 16:02:33 UTC (rev 2081) @@ -1,7 +1,9 @@ -matlab/*.m /usr/lib/dynare/matlab -matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv -matlab/qz/*.m /usr/lib/dynare/matlab/qz -matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker -mex/octave/*.mex /usr/lib/dynare/mex/octave -mex/octave/rcond.m /usr/lib/dynare/mex/octave -preprocessor/dynare_m /usr/lib/dynare/matlab +matlab/*.m /usr/lib/dynare/matlab +matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv +matlab/qz/*.m /usr/lib/dynare/matlab/qz +matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker +matlab/distributions/*.m /usr/lib/dynare/matlab/distributions +matlab/distributions/toolbox/*.m /usr/lib/dynare/matlab/distributions/toolbox +mex/octave/*.mex /usr/lib/dynare/mex/octave +mex/octave/rcond.m /usr/lib/dynare/mex/octave +preprocessor/dynare_m /usr/lib/dynare/matlab
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
OK, let's use 4.0.0-1 type of numbering when we need to correct packaging problems or architecture dependent problems and use 4.0.1 type of numbering for bug fixing releases.
Best
Michel
Sébastien Villemot wrote:
For Debian/Ubuntu, it is necessary to bump the version number (for example 4.0.0-1), otherwise the new package will not overwrite the old one for users who have already installed the buggy version.
This particular bug makes the package quite unusable on Matlab without the statistics toolbox (but not on Octave), at least for estimation, since all distribution related functions are lacking. I fixed it manually in the new ubuntu/amd64 package that I have just uploaded. For other archs, we can either recompile the packages by upgrading the number to 4.0.0-1, or wait till 4.0.1. What's your opinion?
Best
Sébastien
Le mercredi 17 septembre 2008 à 18:07 +0200, Michel Juillard a écrit :
How do we handle these bugs in packaging for one particular architecture?
Do we replace the package silently ? Do we have different version numbers for different packages? Do we make a bug fixing release for all architectures, even if nothing changes in some?
Best
Michel
-------- Original Message -------- Subject: r2081 - dynare_v4/debian Date: Wed, 17 Sep 2008 18:02:33 +0200 From: sebastien@pythie.cepremap.cnrs.fr To: subversion_users@cepremap.cnrs.fr
Author: sebastien Date: 2008-09-17 18:02:33 +0200 (Wed, 17 Sep 2008) New Revision: 2081
Modified: dynare_v4/debian/dynare.install Log: trunk debian/ubuntu packaging: added missing matlab/distributions/ and matlab/distributions/toolbox/ directories
Modified: dynare_v4/debian/dynare.install
--- dynare_v4/debian/dynare.install 2008-09-17 16:00:41 UTC (rev 2080) +++ dynare_v4/debian/dynare.install 2008-09-17 16:02:33 UTC (rev 2081) @@ -1,7 +1,9 @@ -matlab/*.m /usr/lib/dynare/matlab -matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv -matlab/qz/*.m /usr/lib/dynare/matlab/qz -matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker -mex/octave/*.mex /usr/lib/dynare/mex/octave -mex/octave/rcond.m /usr/lib/dynare/mex/octave -preprocessor/dynare_m /usr/lib/dynare/matlab +matlab/*.m /usr/lib/dynare/matlab +matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv +matlab/qz/*.m /usr/lib/dynare/matlab/qz +matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker +matlab/distributions/*.m /usr/lib/dynare/matlab/distributions +matlab/distributions/toolbox/*.m /usr/lib/dynare/matlab/distributions/toolbox +mex/octave/*.mex /usr/lib/dynare/mex/octave +mex/octave/rcond.m /usr/lib/dynare/mex/octave +preprocessor/dynare_m /usr/lib/dynare/matlab
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
Actually the practice of appending a dash-prefixed number (-1) behind the main version number (4.0.0) is used by debian developers who package software developed by people external to debian. This numbering scheme makes sense in a context where package versions are distinct of software version. In our case it is not the case since we do both software development and packaging. Moreover, I think that package problems will be rather rare. It is also more complicated to manage version numbers which can be different accross architectures, for example when dealing with bug reports. So finally I think I prefer the 4.0.1 numbering. We can wait a little bit for updating dynare debian/ubuntu packages, since very few people use it for the moment.
Sébastien
Le mercredi 17 septembre 2008 à 20:38 +0200, Michel Juillard a écrit :
OK, let's use 4.0.0-1 type of numbering when we need to correct packaging problems or architecture dependent problems and use 4.0.1 type of numbering for bug fixing releases.
OK, but we should release 4.0.1 no later than Sept. 30.
Best
Michel
Sébastien Villemot wrote:
Actually the practice of appending a dash-prefixed number (-1) behind the main version number (4.0.0) is used by debian developers who package software developed by people external to debian. This numbering scheme makes sense in a context where package versions are distinct of software version. In our case it is not the case since we do both software development and packaging. Moreover, I think that package problems will be rather rare. It is also more complicated to manage version numbers which can be different accross architectures, for example when dealing with bug reports. So finally I think I prefer the 4.0.1 numbering. We can wait a little bit for updating dynare debian/ubuntu packages, since very few people use it for the moment.
Sébastien
Le mercredi 17 septembre 2008 à 20:38 +0200, Michel Juillard a écrit :
OK, let's use 4.0.0-1 type of numbering when we need to correct packaging problems or architecture dependent problems and use 4.0.1 type of numbering for bug fixing releases.
Dev mailing list Dev@dynare.org http://www.dynare.org/cgi-bin/mailman/listinfo/dev
-
Michel Juillard -
Sébastien Villemot