FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-16-2012, 02:29 PM
Pacho Ramos
 
Default About what would be included in EAPI5

El sáb, 16-06-2012 a las 14:48 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 15:37:44 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > > > About suggesting new item (like forcing rebuilding of other
> > > > packages as discussed some days ago and crosscompile support
> > > > suggested by Tommy today), I guess we need to get them voted by
> > > > the council?
> > >
> > > No. You need to get a draft diff for PMS written, along with an
> > > implementation in a package mangler of your choice and proof that it
> > > works in practice.
> >
> > Umm, this way to work makes any suggestion for future eapis to be
> > accepted only if they come from people able to prepare that
> > implementation in the package manager their prefer and, then, be
> > stalled more and more time :|
>
> It's more of a filter against people saying "EAPI 5 should do blah!"
> where no-one knows what blah actually is (and if you ask five people
> you get six answers) or how it should be implemented, or whether the
> implementation in any way works.
>
> The classic example is multilib: people keep saying "EAPI n+1 should do
> multilib!" where no-one has any idea what "do multilib" means. If you
> asked the Council to vote on that, they'd probably say yes, because
> multilib is good, but it's like politicians voting to say that by next
> year everyone should own a flying car.
>
> Your "forcing rebuild" is similar: the hard part is figuring out the
> problem. You may *think* you know what the issue is, but other people
> think it is something else, and in fact everyone is pretty much wrong
> on the whole thing. Until you've a) worked out what exactly you're
> tryin to solve (no-one has done this yet), b) worked out exactly what
> a solution is, and c) given the solution extensive testing on real
> packages to ensure that step a) didn't miss anything, talking to the
> Council is a waste of everyone's time.
>
> You are of course welcome to try to persuade someone else to do the
> work for you. That's what has happened for a good chunk of the current
> EAPI 5 list, and it's been the same for earlier EAPIs. But what you
> shouldn't do is expect a feature to be introduced just based upon a two
> sentence description, because the best outcome there is that we end up
> giving you something approximately related to what you wanted...
>

I thought last Zac suggestion of ABI_SLOT modified to use "SLOT=ble/bla"
was clear enough and we reached a consensus. About what I am trying to
solve, I have explained it multiple times in involved thread and won't
repeat them once again.
 
Old 06-16-2012, 02:31 PM
Ciaran McCreesh
 
Default About what would be included in EAPI5

On Sat, 16 Jun 2012 16:29:09 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> I thought last Zac suggestion of ABI_SLOT modified to use
> "SLOT=ble/bla" was clear enough and we reached a consensus.

Possibly. I'm waiting to see an implementation, a bunch of examples and
a comparison with just using SLOT and := or :*.

> About what I am trying to solve, I have explained it multiple times in
> involved thread and won't repeat them once again.

Describing the problem clearly and correctly, and in the appropriate
amount of generality, is the hardest and most important part of the
process. Figuring out what we're trying to solve is far harder than
writing a bit of code.

--
Ciaran McCreesh
 
Old 06-16-2012, 02:31 PM
Ciaran McCreesh
 
Default About what would be included in EAPI5

On Sat, 16 Jun 2012 16:29:09 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> I thought last Zac suggestion of ABI_SLOT modified to use
> "SLOT=ble/bla" was clear enough and we reached a consensus.

Possibly. I'm waiting to see an implementation, a bunch of examples and
a comparison with just using SLOT and := or :*.

> About what I am trying to solve, I have explained it multiple times in
> involved thread and won't repeat them once again.

Describing the problem clearly and correctly, and in the appropriate
amount of generality, is the hardest and most important part of the
process. Figuring out what we're trying to solve is far harder than
writing a bit of code.

--
Ciaran McCreesh
 
Old 06-16-2012, 02:52 PM
Ciaran McCreesh
 
Default About what would be included in EAPI5

On Sat, 16 Jun 2012 16:48:20 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Regarding the comparison with using only SLOT, the most clear example
> of how that solution was a bit worse was that glib vs
> dbus-glib/gobject-introspection handling:
> - Using only SLOT with := would end up with we needing to update
> ebuilds for packages depending on glib on each SLOT bump, that is
> completely inviable.

What about if ranged dependencies existed?

Also, we've yet to establish whether SLOT-with-/ really solves this
problem, nor whether the problem is a general one. How many packages
are there with stable APIs but unstable ABIs?

> - I suggested then to be able to make that packages depend on :* (for
> example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to
> get their ebuilds updated as they would still fit inside "2.*" case,
> but would still get rebuild (as wanted) due := usage... but you also
> didn't like this approach.

You're misunderstanding the point of the * there. The * has nothing to
do with wildcarding.

> > > About what I am trying to solve, I have explained it multiple
> > > times in involved thread and won't repeat them once again.
> >
> > Describing the problem clearly and correctly, and in the appropriate
> > amount of generality, is the hardest and most important part of the
> > process. Figuring out what we're trying to solve is far harder than
> > writing a bit of code.
>
> What I try to do is to replace the needing of manually rebuilding
> packages after updates due ABI changes, like currently occurs with
> xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like
> that.

See, that's not really a description of the problem. It's a good start,
but I'd expect a full description to run to be several pages of
detailed description of the general case, along with worked out
examples. This isn't an easy issue, and we don't want to come up with a
solution that works for one particular package whilst ignoring the
needs of everything else.

> Regarding other problems like needing to use perl-cleaner,
> python-updater looks to be covered by another approach of "dynamic
> slots" I have just seen in gentoo-dev IRC channel by mgorny, then,
> that kind of issues would be uncovered with this (but maybe I am
> wrong as I know Zac had a more clear conception about how this
> ABI_SLOT way would work and what would it cover)

Somehow I don't think this cunning plan has been thought all the way
through...

Coming up with a "solution" rather than a description of the problem is
the wrong thing to do.

--
Ciaran McCreesh
 
Old 06-16-2012, 03:06 PM
Peter Stuge
 
Default About what would be included in EAPI5

Pacho Ramos wrote:
> What I try to do is to replace the needing of manually rebuilding
> packages after updates due ABI changes

Does this really require explicit ABI information in ebuilds?

Could it work to make automatic signatures of imported ABI, and
simply compare signatures when a provider package is updated?


//Peter
 
Old 06-16-2012, 03:08 PM
Ciaran McCreesh
 
Default About what would be included in EAPI5

On Sat, 16 Jun 2012 17:06:07 +0200
Peter Stuge <peter@stuge.se> wrote:
> Could it work to make automatic signatures of imported ABI, and
> simply compare signatures when a provider package is updated?

No.

Also, can we stop using the term "ABI" in reference to this please?
It's misleading. Let's call them sub-slots instead.

--
Ciaran McCreesh
 
Old 06-16-2012, 03:16 PM
Pacho Ramos
 
Default About what would be included in EAPI5

El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 16:48:20 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > Regarding the comparison with using only SLOT, the most clear example
> > of how that solution was a bit worse was that glib vs
> > dbus-glib/gobject-introspection handling:
> > - Using only SLOT with := would end up with we needing to update
> > ebuilds for packages depending on glib on each SLOT bump, that is
> > completely inviable.
>
> What about if ranged dependencies existed?

I think this was already discussed in the same thread, but maybe we are
thinking in different things, could you please explain me a bit more
what do you mean by "ranged dependencies"? (if it would include an
example, even better )

>
> Also, we've yet to establish whether SLOT-with-/ really solves this
> problem, nor whether the problem is a general one. How many packages
> are there with stable APIs but unstable ABIs?
>

Good point, if other maintainers don't talk about their packages (as
they will for sure know why they need rebuilding exactly), would need to
grep in the tree looking for rebuild instructions for figure out :/, I
can try to check it if no maintainer shows more packages showing this
stable API unstable ABIs issues

> > - I suggested then to be able to make that packages depend on :* (for
> > example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to
> > get their ebuilds updated as they would still fit inside "2.*" case,
> > but would still get rebuild (as wanted) due := usage... but you also
> > didn't like this approach.
>
> You're misunderstanding the point of the * there. The * has nothing to
> do with wildcarding.

Probably, what is "*" sense in this context? I was thinking more on a
bash context when I would use "*" to fit any 2.x case

>
> > > > About what I am trying to solve, I have explained it multiple
> > > > times in involved thread and won't repeat them once again.
> > >
> > > Describing the problem clearly and correctly, and in the appropriate
> > > amount of generality, is the hardest and most important part of the
> > > process. Figuring out what we're trying to solve is far harder than
> > > writing a bit of code.
> >
> > What I try to do is to replace the needing of manually rebuilding
> > packages after updates due ABI changes, like currently occurs with
> > xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like
> > that.
>
> See, that's not really a description of the problem. It's a good start,
> but I'd expect a full description to run to be several pages of
> detailed description of the general case, along with worked out
> examples. This isn't an easy issue, and we don't want to come up with a
> solution that works for one particular package whilst ignoring the
> needs of everything else.
>
> > Regarding other problems like needing to use perl-cleaner,
> > python-updater looks to be covered by another approach of "dynamic
> > slots" I have just seen in gentoo-dev IRC channel by mgorny, then,
> > that kind of issues would be uncovered with this (but maybe I am
> > wrong as I know Zac had a more clear conception about how this
> > ABI_SLOT way would work and what would it cover)
>
> Somehow I don't think this cunning plan has been thought all the way
> through...
>
> Coming up with a "solution" rather than a description of the problem is
> the wrong thing to do.
>
 
Old 06-16-2012, 03:20 PM
Pacho Ramos
 
Default About what would be included in EAPI5

El sáb, 16-06-2012 a las 17:16 +0200, Pacho Ramos escribió:
> El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> > On Sat, 16 Jun 2012 16:48:20 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > > Regarding the comparison with using only SLOT, the most clear example
> > > of how that solution was a bit worse was that glib vs
> > > dbus-glib/gobject-introspection handling:
> > > - Using only SLOT with := would end up with we needing to update
> > > ebuilds for packages depending on glib on each SLOT bump, that is
> > > completely inviable.
> >
> > What about if ranged dependencies existed?
>
> I think this was already discussed in the same thread, but maybe we are
> thinking in different things, could you please explain me a bit more
> what do you mean by "ranged dependencies"? (if it would include an
> example, even better )
>
> >
> > Also, we've yet to establish whether SLOT-with-/ really solves this
> > problem, nor whether the problem is a general one. How many packages
> > are there with stable APIs but unstable ABIs?
> >
>
> Good point, if other maintainers don't talk about their packages (as
> they will for sure know why they need rebuilding exactly), would need to
> grep in the tree looking for rebuild instructions for figure out :/, I
> can try to check it if no maintainer shows more packages showing this
> stable API unstable ABIs issues
>

Also, maybe you could talk with other exherbo maintainers as I am sure
they have also experienced this kind of problem (packages needing to be
rebuilt after update of other one), maybe they could join forces with us
to try to reach an exact description of the problem and a solution :/

> > > - I suggested then to be able to make that packages depend on :* (for
> > > example, dev-libs/glib:2.*:=, that way, that packages wouldn't need to
> > > get their ebuilds updated as they would still fit inside "2.*" case,
> > > but would still get rebuild (as wanted) due := usage... but you also
> > > didn't like this approach.
> >
> > You're misunderstanding the point of the * there. The * has nothing to
> > do with wildcarding.
>
> Probably, what is "*" sense in this context? I was thinking more on a
> bash context when I would use "*" to fit any 2.x case
>
> >
> > > > > About what I am trying to solve, I have explained it multiple
> > > > > times in involved thread and won't repeat them once again.
> > > >
> > > > Describing the problem clearly and correctly, and in the appropriate
> > > > amount of generality, is the hardest and most important part of the
> > > > process. Figuring out what we're trying to solve is far harder than
> > > > writing a bit of code.
> > >
> > > What I try to do is to replace the needing of manually rebuilding
> > > packages after updates due ABI changes, like currently occurs with
> > > xorg drivers, g-i and dbus-glib, ocaml-c based apps and cases like
> > > that.
> >
> > See, that's not really a description of the problem. It's a good start,
> > but I'd expect a full description to run to be several pages of
> > detailed description of the general case, along with worked out
> > examples. This isn't an easy issue, and we don't want to come up with a
> > solution that works for one particular package whilst ignoring the
> > needs of everything else.
> >
> > > Regarding other problems like needing to use perl-cleaner,
> > > python-updater looks to be covered by another approach of "dynamic
> > > slots" I have just seen in gentoo-dev IRC channel by mgorny, then,
> > > that kind of issues would be uncovered with this (but maybe I am
> > > wrong as I know Zac had a more clear conception about how this
> > > ABI_SLOT way would work and what would it cover)
> >
> > Somehow I don't think this cunning plan has been thought all the way
> > through...
> >
> > Coming up with a "solution" rather than a description of the problem is
> > the wrong thing to do.
> >
>
>
 
Old 06-16-2012, 03:24 PM
Peter Stuge
 
Default About what would be included in EAPI5

Ciaran McCreesh wrote:
> > Could it work to make automatic signatures of imported ABI, and
> > simply compare signatures when a provider package is updated?
>
> No.

Can you say why?


> Also, can we stop using the term "ABI" in reference to this please?
> It's misleading. Let's call them sub-slots instead.

I think ABI fits well though? The situation is that A DEPENDs on B,
and at some point B changes in a way that A must be rebuilt in order
to run - right?

The only reason that A wouldn't run anymore is that B's ABI changed?

Slots and sub-slots seem to be PMS terms to model this situation?
They could certainly be used to implement a solution, but perhaps
it's wise not to insist on using them when merely exploring the
problem?


//Peter
 
Old 06-16-2012, 04:24 PM
Ciaran McCreesh
 
Default About what would be included in EAPI5

On Sat, 16 Jun 2012 17:16:34 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> > On Sat, 16 Jun 2012 16:48:20 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > > Regarding the comparison with using only SLOT, the most clear
> > > example of how that solution was a bit worse was that glib vs
> > > dbus-glib/gobject-introspection handling:
> > > - Using only SLOT with := would end up with we needing to update
> > > ebuilds for packages depending on glib on each SLOT bump, that is
> > > completely inviable.
> >
> > What about if ranged dependencies existed?
>
> I think this was already discussed in the same thread, but maybe we
> are thinking in different things, could you please explain me a bit
> more what do you mean by "ranged dependencies"? (if it would include
> an example, even better )

Being able to say something like >=2&<3.

> I can try to check it if no maintainer shows more packages
> showing this stable API unstable ABIs issues

Please do. This is a fairly important point: if the number of affected
packages is small, there's no point in introducing sub-slots.

> > You're misunderstanding the point of the * there. The * has nothing
> > to do with wildcarding.
>
> Probably, what is "*" sense in this context? I was thinking more on a
> bash context when I would use "*" to fit any 2.x case

It means "and the slot can be switched at runtime, without causing
breakage". Thus it's only meaningful on dependencies that are both
build- and run-.

The :*/:= feature was designed to solve one specific problem: if a user
has foo installed, and foo deps upon bar, and bar:1 is installed, and
the user wants to install bar:2 and then uninstall bar:1, will foo
break? :* means no, := means yes.

> Also, maybe you could talk with other exherbo maintainers as I am sure
> they have also experienced this kind of problem (packages needing to
> be rebuilt after update of other one), maybe they could join forces
> with us to try to reach an exact description of the problem and a
> solution :/

I'm pretty sure the route Exherbo is going to take with this is very
different, and will involve souped-up USE flags that allow "parts" of a
package (such as its libraries) to be kept around, possibly together
with a special form of blocker that acts only upon installed packages,
with a strict post ordering. It's not going to involve sub-slots, in
any case.

--
Ciaran McCreesh
 

Thread Tools




All times are GMT. The time now is 10:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org