I am Emmanouil Kiagias a Debian gsoc student and my mentor is Andreas Tille. The gsoc project goal is to redesign the metapackage creation for Debian Blends [1].
I am bringing up a question to this list from the blends-list [2] . We actually want to achieve architecture dependent metapackages for Blends and thus now we have to deal me the syntax of the debian/control file. Here is the part of the discussion[2]:
> 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.
> >
> >
> Emmanouil Kiagias <e.kiagias@gmail.com> wrote:
> 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?
Andreas Tille <andreas@an3as.eu> wrote:
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.
------------------------------------------------------------------------------------
So the question is, can we have multiple debian/control.<arch> files(per architecture) ? And when the binary packages are build from the source how the debian/control with the correct architecture will come to effect? Or in case we have one control file what syntax should the file follow in order our source package can fit *all* architectures. Any suggestions or ideas is more than welcome. Thanks for your time.