Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)

[Emmanouil Kiagias <e.kiagias@gmail.com>]

Hello Andreas,

I have some notes for the current blends-dev implementation:

As I saw in the blends/devtools/Makefile the produced debian/control file is built as following:

* first it contains the content of the debian/control.stub. this file contains the blend info along with extra fields such as Build-Depends-Indep, priority etc (the UDD blends_metadata contains most of these data, also the UDD sources)

  I assume my script will get the blend-name for the control.stub file (like the current blend-gen-control does)

* then the Makefile checks if a config/control file  exists, if yes it also "appends" its content in the debian/control file

* finally the blend-gen-control is called and "appends" the tasks info in the final debian/control.

I assume that the first two steps are going to be the same? Then the new blend-gen-control will dump in the stdout (or append in an existing file) the task info (the rest will be taken from the control.stub and config/control). I also assume the new blend-gen-control should will the -D argument(lower all Depends: to Recommends:).

Also I observed that the "Avoid" packages are not saved in the UDD blends_dependencies(thus we can not have the excluded list as the curreny blends-dev has). For the moment blends-gen-control will keep a list of the "missing packages" while creating the blends_dependecies dictionary needed for gen_control method. 

On Fri, Jun 21, 2013 at 10:15 AM, Andreas Tille <andreas@an3as.eu> wrote:

  --architecture: This is more complex.  Finally we want to build *one*
             source package that fits *all* architectures.  For the moment
             we could go with the manual specification (or setting the
             currrent architecture as default).  However, finally you will
             need to dig the archives / ask on mailing lists what syntax to
             use to get a source package that will create the right
             dependencies according to the architecture the source package
             was build on.  There are such packages inside the Debian
             archive but I admit I never dealt with this before and also
             would need to do some research first
             So what we create is a source package containing either one
             control file or several of them (one for each architecture)
             and once the binary packages are built from this source the
             correct architecture needs to come into effect to get the
             correct dependencies for this architecture.

 

According to this reference about the control file syntax: http://www.debian.org/doc/debian-policy/ch-controlfields.html a package can have several architectures:

"Specifying a specific list of architectures indicates that the source will build an architecture-dependent package only on architectures included in the list. Specifying a list of architecture wildcards indicates that the source will build an architecture-dependent package on only those architectures that match any of the specified architecture wildcards. "

In this case if we can have multiple architectures per package(or eg: "any" which matches all Debian architectures ) but: What actually blend-gen-control does is that it checks if the "depends" packages if they exists in the target architecture, if not it adds the "depends" to "suggests" making sure the installation will not try to install an not existing package. If we apply the same method for all the possible Debian architectures per package, we will end up with having almost an empty  "depends" list, and all depends will go to suggests. (only the "all" packages will stay as is and the packages which exist for *all* Debian architectures), so having a  separate control file for each architecture sounds for convincing(for the moment). But the problem/question is that in case we have several control files how will the correct control/architecture come in effect when the binary packages are buil?t (I have to investigate and study more in order to obtain a better/clear understanding how this works). Can you suggest any other source than the Debian policy about the source syntax we have to use?

For the moment I will make the blend-gen-control create a control file for a given architecture. Also how do you prefer to dump the task-info? straight to stdout as the current blend-dev does or dump it/append in a file?   

Kind regards

Emmanouil