El jue, 07-06-2012 a las 20:16 +0200, Pacho Ramos escribió:
> El jue, 07-06-2012 a las 11:03 -0700, Zac Medico escribió:
> > On 06/07/2012 10:40 AM, Ciaran McCreesh wrote:
> > > On Thu, 07 Jun 2012 09:43:32 -0700
> > > Zac Medico <email@example.com> wrote:
> > >> I can imagine that ABI_SLOT operator deps will be a lot more popular
> > >> than SLOT operator deps, since ABI_SLOT operator deps will accommodate
> > >> the common practice of allowing ABI changes within a particular SLOT.
> > >
> > > You're missing out on a brilliant opportunity to encourage developers
> > > put in a bit more work to save users a huge amount of pain here.
> > What about cases like the dbus-glib and glib:2 dependency, where it's
> > just too much trouble to use SLOT operator deps? Wouldn't it be better
> > to have a little flexibility, so that we can accommodate more packages?
> > As a workaround for SLOT operator deps, I suppose that glib:1 could be
> > split into a separate glib-legacy package, in order to facilitate the
> > use of SLOT operator dependencies in dbus-glib. That way, it would be
> > easy to match glib-2.x and not have to worry about trying not to match
> > glib-1.x.
> I would prefer, as a workaround, allow reverse deps to RDEPEND on
> glib:2.* instead. That way it would cover more cases when more than two
> slots are available
looks like "*" usage for SLOTs would be allowed :), or I am