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 <pa...@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. > > > >
signature.asc
Description: This is a digitally signed message part
