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

Hello Andreas,

On Wed, Jul 24, 2013 at 10:17 AM, Andreas Tille <andreas@an3as.eu> wrote:

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?

No I don't think so. There were some interesting talks like: advice for freelancing, measure I/O latency in cloud systems. And generally talks about the openSUSE community itself.

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

Hmm, I didn't think of this. I'll keep that in mind also for the existing {sec-}blend-gen-control

> 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

Yes it helps, thanks for the rephrase :-).

I will implement the new single control file approach as you mention into the rephrase items.

For the moment I will keep the existing {sec-}blend-gen-control as is concerning the Depends packages which move to Suggests when they are not available for a specific arch. Later we can reconsider it and change it.

Kind regards

Emmanouil