Hello Andreas,
On Wed, Jul 24, 2013 at 10:17 AM, Andreas Tille <[email protected]> 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
