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

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Mon, Jun 24, 2013 at 02:40:09PM +0300, Emmanouil Kiagias wrote:
> * 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)

Yes.

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

Yes.

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

Yes.

> I assume that the first two steps are going to be the same?

Yes.

> 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:).

For the moment yes but it might be debatable.  I have always wondered whether
there could be a need to force a real Depends.  So once we are reimplementing
things we could consider changing the meaning of the tasks files, substitute
current Depends by Recommends and enable real Depends by stop replacing them
(perhaps by issuing a warning or so).  We might discuss this in a later state
or now.

> 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).

A - seems I should fix this in the UDD importer!

> 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.

Fine.

> 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?

I think the option above is not really what we want / need.  We will end up
with packages Pi on architectures Aj where for instance

   P1 is available on A1, A2, A3, A4
   P2 is available on A1,     A3
   P3 is available on A1,         A4
   P4 is available on     A2
   etc.  

You can not really implement this with the syntax above.  I think you
might get an idea about a possible solution for instance from the source
package of the binary package openjdk-7-jre.  Why do I think this?  When
working on web sentinel I stumbled upon the fact that it is possible
that the same binary package can have different descriptions which can
easily be checked via:

udd=# SELECT DISTINCT package, architecture, description from packages where package like 'openjdk-7-jre' ORDER BY package, architecture ;
    package    |  architecture  |               description                
---------------+----------------+------------------------------------------
 openjdk-7-jre | amd64          | OpenJDK Java runtime, using Hotspot JIT
 openjdk-7-jre | armel          | OpenJDK Java runtime, using Hotspot Zero
 openjdk-7-jre | armhf          | OpenJDK Java runtime, using Hotspot Zero
 openjdk-7-jre | i386           | OpenJDK Java runtime, using Hotspot JIT
 openjdk-7-jre | ia64           | OpenJDK Java runtime, using Hotspot Zero
 openjdk-7-jre | kfreebsd-amd64 | OpenJDK Java runtime, using Hotspot JIT
 openjdk-7-jre | powerpc        | OpenJDK Java runtime, using Hotspot Zero
 openjdk-7-jre | s390           | OpenJDK Java runtime, using Hotspot Zero
 openjdk-7-jre | s390x          | OpenJDK Java runtime, using Hotspot Zero
 openjdk-7-jre | sparc          | OpenJDK Java runtime, using Hotspot JIT

So here we have different effective control files from one source for
the binaries of different architectures and thus it could give an idea
how we could do this similarly.

It might also be a good idea to bring up this question on the
debian-mentors@lists.debian.org mailing list.

> For the moment I will make the blend-gen-control create a control file for
> a given architecture.

You can easily create a set of all debian/control.<arch> files in a
loop.  I think this should be tested from time to time to detect
problems in our approach for rarely used architectures soonish.

> 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?

You mean the tasksel input file <blendname>-tasks.desc?

I do not have a real preference here.  It just needs to work somehow.
(It should be clear that also this needs to be a set of
<blendname>-tasks.desc.<arch> files - but here it is way simpler to
pick the right one which can be easily done in the rules file.
 
Kind regards
 
    Andreas.

-- 
http://fam-tille.de