[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Hello Andreas,

On Mon, Jul 15, 2013 at 10:07 AM, Andreas Tille <andreas@an3as.eu> wrote:

> Let's take the control file for architecture kfreebsd-amd64
> For kfreebsd-amd64, testing release virtual package "nfs-server" is
> available but "nfs-kernel-server" package is not. So blend-gen-control
> correctly places "nfs-server" in Depends: and "nfs-kernel-server" in
> Suggests:.

Well, this is actually *incorrect*!  If a control file contains a
virtual package you should make sure that there is a really existing
alternative given.  In other words: you would trigger the following
lintian warning


when delivering a control file that only mentions a virtual package.  I
think I remember the usage was described in policy or developers
reference but failed to find this with a very quick search - you will
definitely find something when seeking more deeply.  The problematic
phrase in your arguing is: 'virtual package "nfs-server" is available'.
By definition virtual packages are *not* available - they are just
virtual and need to be provided by a real package.  If there is no such
real package the whole set of alternatives should be moved to Suggests.

I changed a little sec-blend-gen-control and now it follows the case you described. In case there is a virtual package in Depends which does not list any real package as an alternative then it moves to the Suggests(or a whole set of alternatives-virtuals is moved to Suggests). Comparing the two {sec-}blend-gen-control I also noticed that there is a case like that in Blend openstudio:

   blend    |   task   |  alternatives  | dependency | contains_provides 
 openstudio | firewire | jackd-firewire | d          | t

Now sec-blend-gen-control correctly places  jackd-firewire in Suggests(even if there is a real package available to provide it).  On the other hand blend-gen-control, which is not updated yet, places  jackd-firewire virtual as standalone into Depends.So sec-blend-gen-control  seems to handle these cases properly.

I will now update blend-gen-control to also handle these cases.

For the moment these are my todo:

* Update blend-gen-control for handling virtual-package-depends-without-real-package-depends
* Sum up all the missing packages problematic cases/differences from {sec-}blend-gen-control output.
 as you told me in a previous mail:
For the moment I do not have any hints for enhancing tasks_diff.

BTW, yesterday I have seen in some control file:

   Build-Depends: pkg1 [!arch1 !arch2 !arch3], pkg2 [!arch1], ...

This might be an idea for an alternative way to create a single control
file (after having checked the relevant docs which I did not - may be
this is only valid for Build-Depends which I doubt but checking might
not harm).

 * check alternative way to create single control file

Once I cover the above todos what should come next( today-tomorrow and next week)? How should we continue?

 Kind regards


Reply to: