Le 21/11/2012 17:48, Ian Jackson a écrit :
>> Although I'd agree that defining a new lv2-plugin would not be needed,
>> making LV2 plugins packages Depend/Recommend a generic lv2-host
>> package would seriously help as it allows maintainers to avoid to fill
>> up Depends: fields with long and incom
On 21 Nov 2012, at 17:27, Russ Allbery wrote:
> don't know if Ian is, but I certainly would. We have a bunch of
> existing virtual packages that aren't really useful because they don't
> offer any sort of guaranteed interface, and therefore cannot be
> meaningfully used in package relationships
On 21/11/12 17:27, Russ Allbery wrote:
> Without that, it's questionable whether the
> virtual package serves any purpose, and indeed you'll find that the CD
> ripping packages in Debian don't reference mp3-encoder
... and perhaps more tellingly, only one package Provides it, and that
package isn'
Alessio Treglia writes:
> Why tightening up rules? Policy §3.6 does not pretend packages to meet
> any specs nor comply with common interfaces, it just says "Sometimes
> there are several packages which offer more-or-less the same
> functionality. In this case, it's useful to define a virtual pac
Jonas Smedegaard writes:
> It seems to me that you are applying more strict rules now than has been
> applied to other names on the list in the past.
I don't know if Ian is, but I certainly would. We have a bunch of
existing virtual packages that aren't really useful because they don't
offer an
Alessio Treglia writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> On Wed, Nov 21, 2012 at 3:03 PM, Ian Jackson
> wrote:
> > So I'm afraid I still don't understand how this virtual package would
> > help improve the dependency resolution.
>
On Wed, Nov 21, 2012 at 3:03 PM, Ian Jackson
wrote:
> So I'm afraid I still don't understand how this virtual package would
> help improve the dependency resolution.
Although I'd agree that defining a new lv2-plugin would not be needed,
making LV2 plugins packages Depend/Recommend a generic lv2-h
On 21 November 2012 22:51, Alessio Treglia wrote:
> Actually I receive lots of mails from users asking me questions like "How
> could
> I find an exhaustive list of LV2 toys currently provided by Debian?", "Does
> the
> X sequencer support LV2 plugins?". So, I think we'd do a good service to our
> Why tightening up rules? Policy =C2=A73.6 does not pretend packages
> to meet= any specs nor comply with common interfaces, it just says
> "Sometimes there are severa= l packages which offer more-or-less the
> same functionality. In this case, it'= s useful to define a virtual
> package whose nam
On Wed, Nov 21, 2012 at 12:40 PM, Ian Jackson
wrote:
> I guess you are thinking that LV2 plugin packages would Recommend or
> Depend on lv2-host ?
Yes, exactly.
> But I don't think that's really helpful.
> Perhaps lv2-host should specify something more definite, like "can
> access the following
Jonas Smedegaard writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> It seems to me that you are applying more strict rules now than has been
> applied to other names on the list in the past.
This is not some kind of hazing ritual where people have to persuade a
re
Quoting Ian Jackson (2012-11-21 13:40:35)
> Alessio Treglia writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> > On Tue, Nov 20, 2012 at 2:27 PM, Ian Jackson
> > wrote:
> > > And an lv2-host could include something which can use only p
Alessio Treglia writes ("Re: New virtual packages: lv2-plugin and lv2-host"):
> On Tue, Nov 20, 2012 at 2:27 PM, Ian Jackson
> wrote:
> > And an lv2-host could include something which can use only plugins
> > with certain features.
>
> Altough dillo doesn
Hi Ian,
thanks for the quick reply!
On Tue, Nov 20, 2012 at 2:27 PM, Ian Jackson
wrote:
> An lv2-plugin could be almost anything AFAICT, so depending on "some
> LV2 plugin" is not very useful.
>
> And an lv2-host could include something which can use only plugins
> with certain features.
Altoug
Alessio Treglia writes ("New virtual packages: lv2-plugin and lv2-host"):
> virtual-package-list.txt.gz [1] says:
>
>1. Post to debian-devel saying what names you intend to use or what
> other changes you wish to make, and file a wish list bug against the
> package debian-policy.
>
15 matches
Mail list logo
