[GSoC] Different control files when building for different architectures (Was: blends-dev gsoc 2013, debian/control file)
Hi,
I'd like to rephrase this question a bit (and also fixed the spacing of
my quote in my example query below a bit which was somehow spoiled a
bit). We found a way to create a set of debian/control.<arch> files.
What would you consider the best way to make sure to bring the correct
control file into effect when building on a specific architecture?
I could imagine some kind of debian/control dummy file that will be
saved and replaced in the build target and restored in the clean target.
Seems to be doable but somehow hackish. Any better suggestion?
Kind regards
Andreas.
On Tue, Jun 25, 2013 at 11:30:01AM +0300, Emmanouil Kiagias wrote:
> Hello,
>
> 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.
>
>
> Kind regards
>
> Emmanouil
>
>
> [1]:
> http://wiki.debian.org/SummerOfCode2013/StudentApplications/EmmanouilKiagias
> [2]: http://lists.debian.org/debian-blends/2013/06/msg00023.html
--
http://fam-tille.de
Reply to: