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

Re: Redesign metapackage creation for Debian Blends

Hello Andreas

As you noticed the debian/control file is auto generated depending from
the content of the package pool.  In unusual cases this could mean that
without any manual change in the source the resulting source package
could be different from a previous version simply because packages were
added (or removed) from the package pool.  These kind of changes are
not reflected inside debian/changelog ... but should.  I imagine the
following for debian/changelog (here using Debian Med example):

debian-med (1.14) unstable; urgency=low

  * Build-Depends: blends-dev (>= 0.6.17)
  * ...

  * Changes in metapackage dependencies
    - med-bio:
       added: package_a, package_b, ...
       removed (optional): ...
    - med-...
  * New metapackages
    - med-...

 -- Andreas Tille <tille@debian.org> [creation date / time]

debian-med (1.13.2) unstable; urgency=low

To solve this we need some way to store the old dependency list of
the previous package.  Some json file comes to mind and it would
not harm to store the dependency status of *all* versions inside
such a json database.  This could in addition come very handy for
the team analysis I did in


   in dir misc/team_analysis_tools

which in this case would boil donw to graphing this json file rather
than checking VCS tags.

Ok now I understand. The json file solution to save the dependency status of all the versions seems quite nice and straightforward. Also it will be will easy manageable with python and as you said quite useful for your team analysis.

The next days I will start preparing my proposal. Should I also add to the project details the changelog entry creation to track the added and removed packages(per task) between releases?

Is there anything else you would suggest me to check?

Kind regards

Emmanouil Kiagias

Reply to: