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

Re: reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.




On Nov 23, 2014 6:14 AM, "Jonas Smedegaard" <dr@jones.dk> wrote:
>
> Quoting Reinhard Tartler (2014-11-23 02:57:33)
> > On Thu, Nov 20, 2014 at 9:02 PM, Jonas Smedegaard <dr@jones.dk> wrote:
> >> Quoting Reinhard Tartler (2014-11-20 21:45:56)
> >>> On Nov 20, 2014 3:01 PM, "Jonas Smedegaard" <[1]dr@jones.dk> wrote:
> >>>> Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
> >>>>> On 19.11.2014 13:09, Jonas Smedegaard wrote:
> >>>>>> Possibly we can simplify even further:
> >>>>>>
> >>>>>>  * Have package libavcodec-extra-NN provide virtual
> >>>>>>    libavcodec-extra (i.e. non-versioned name of itself)
> >>>>>>  * Let GPLv2 packages conflict against libavcodec-extra (i.e. not
> >>>>>>    replace but complement existing suggests/recommends/depends).
> >>>>>>
> >>>>>> How does that sound?
> >>>>>
> >>>>> This sounds good, except that the virtual package needs another
> >>>>> name, because libavcodec-extra is actually a real package [1].
> >>>>
> >>>> I don't see a problem in conflicting both with virtual provisions
> >>>> of the package and the real package - as the latter seems to me to
> >>>> provide nothing beyond pulling in latest of those same virtual
> >>>> provisions.
> >>>
> >>> I'm pretty sure that this approach makes it impossible to have a
> >>> versioned dependency on libavcodec-extra. Not sure if there is an
> >>> actual need for this, though.
> >>
> >> Now you get me curious: How would providing a virtual package make it
> >> any more difficult to depend versioned on a package?
> >
> >
> > AFAIUI, if you have libavcodec-extra both virtual and real, then
> > application packages can no longer declare:
> >
> > Depends: libavcodec-extra (>> 6:11)
> >
> > And reliably expect that the version constraint is obeyed. Or am I
> > missing something?
>
> Until recently, declaring a versioned dependency against a package both
> real and virtual meant that only the real package was considered, by the
> logic that only real packages can satisfy a version constraint.

Oh, if that is the case, then your idea of adding the provides, and having maintainers of gplv2 only packages conflict against libavcodec-extra sounds very appealing to me, because only the special cases need work.

Let's do that then

Best
Reinhard


Reply to: