Yes, that's it. (It also creates a tasksel control file, but that comes
On Tue, Apr 16, 2013 at 01:26:28AM +0300, Emmanouil Kiagias wrote:
> I took a look into the existing perl code and I think the project got more
> clear now, I will try to describe it in a few simple words:
> The current the blend-gen-control does an apt-get update and creates a
> package pool, from the apt-cache dump output, with all the available
> packages , then it loads the tasks files and finally generates a control
> file according to the available packages(it verifies if the the described
> dependencies in the tasks files exist in the package pool).
similarly cheap as the debian/control file technically.)
> The new python design should create a package pool using information from
> UDD(get available packages' information similar to apt-cache dump's
> output). In that case it can create architecture dependent package
> pool(query packages' information for a specific architecture instead of
> using the architecture from where the blends-dev was called ) and so create
> architecture dependent metapackages.
> Is this approach correct?
We should also try to achieve some kind of changelog entry creation
between the latest release and the current release that lists added
and removed packages per task. This was requested by release team
Hint: I'm subscribed to debian-blends mailing list and if you confirm
you are reading this list as well I will stop CCing you as it is
the usual policy on Debian lists.