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

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Tue, Jul 23, 2013 at 09:54:45PM +0300, Emmanouil Kiagias wrote:
> I was offline on Friday(I included that on my report) and the past 3 days.
> I was invited to go to Thessaloniki by a friend to attend at openSUSE
> conf[0]

That's fine.  Anything we should know here from this conference?

> and thus I was offline the past 4 days,

Hmmmmm, at DebConf you will *not* be offline. ;-)

> mostly because of
> travelling(sorry I should have mentioned this earlier but it was a last
> minute decision). I will have covered up the working hours by the end of
> the week.

That'*s perfectly OK.

> I read again Debian Policy Manual in order to check for the control file
> alternative syntax. From here[1] it seems that the syntax you mentioned is
> also valid for the Depends field.  So we can have Depends header like:
> 
> Depends: foo [i386], bar [amd64]
> 
> or
> 
> Depends: foo [!i386], bar [!amd64] etc.

Fine.  This might be helpful in terms of no need to fiddle around with
different control files.

> So my first idea is to add "Architecture: any" in our packages, for example:
> 
> Package: med-bio
> Architecture: any
> Priority: extra
> Depends: foo [!i386], bar (etc..)

Yep.  Exactly this was my idea.

> So in this case any "Depends" package which is not in Debian distribution
> and the main component will be moved to "Suggests"(as we are doing now) and
> the rest of the packages(debian,main) will stay in Depends but they will
> exclude the architectures in which they are not available. For example if
> the package "foo" is available in all architectures except kfreebsd-amd64
> and kfreebsd-i386 it will be like:
> 
> Depends: foo [!kfreebsd-amd64 !kfreebsd-i386 ] ...

I think this is perfectly OK.  If a package is not available for a
certain architecture this is for a reason.  Chances that you can obtain
the package from any other external source are very close to zero - so
suggesting those packages for architectures is totally useless.
Actually when thinking twice about it it is the correct way to *not*
suggest packages that exist for other architectures for a certain
architecture where the package does not exist.

> In this case I have a question. If the -D argument is passed into the
> blend-gen-control then the Depends are fixed like:
> 
> Depends: med-tasks (= ${binary:Version})
> 
> and the "Depends" are added into the "Recommends". So in case of -D the
> control file should be like the following: ?(does it make sense to exclude
> an architecture from the Recommends header?)
> 
>  Depends: med-tasks (= ${binary:Version})
>  Recommends: foo [!kfreebsd-amd64 !kfreebsd-i386 ]

I'm not fully sure whether I understand the question correctly so I try
to rephrase:

  1. Yes, we want recommends of certain packages (no depends)
  2. Yes, we want to exclude certain architectures if the package does
     not exist here.
  3. A package should not show up in Suggests if it exists for one
     single architecture (at least)
  4. Item 3. should even apply if we consider the control.<arch>
     approach we previously considered - there is no point in suggesting
     a package if there seem to be reasons why a certain architecture
     does not feature this software.

Hope this helps

     Andreas.
 
> [0]: https://conference.opensuse.org/
> [1]: http://www.debian.org/doc/debian-policy/ch-relationships.html

-- 
http://fam-tille.de