Re: Bug#785678: blends-dev: Do not drop virtual packages in alternatives
Hi Felipe,
thanks for this bug report. I confirm that this is actually an issue
that should be fixed. However, I intend to switch to the blends-dev
code base developed in GSoC 2013 in the Jessie release cycle basically
because it will enable architecture dependant metapackages. The current
blends-dev just uses the build machine (in my case amd64) to decide
what package is available which is simply wront. The new code checks
UDD for creating the list of architectures which is more correct but
requires creating the blends source package on a machine with access
to an UDD instance (alioth for instance). And it needs more testing.
I'm hesitating to fix this bug in the old code base since I hope I will
be able to use DebCamp to work on the final switch. (As always a patch
could convince me to be faster ;-))
On Tue, May 19, 2015 at 10:09:32AM +0800, Paul Wise wrote:
> On Tue, May 19, 2015 at 9:15 AM, Felipe Sateler wrote:
>
> > I use blends-dev to create local metapackages. I sometimes use the
> > common real-package | virtual-package pattern to specify a default but
> > allow alternatives. However, blends-dev removes the virtual-package
> > alternatives since they do not exist. It would be great if one could
> > pass an option or something to allow nonexistent packages in Depends
> > lines.
>
> I think it would be better if blends-dev could know which virtual
> packages exist and allow them in Depends, but not allow non-existent
> real or virtual packages. Since dpkg now allows versioned Provides, it
> would also need to check the version constraints are correct.
I need to verify but I think in UDD we can use a list of virtual
packages so yes, this suggestion will be probably implemented.
Moreover I think we should implement some test suite that guaranties
that this kind of problems will be detected quickly.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: