On Tue, Dec 08, 2009 at 06:21:09PM +0100, Julian Andres Klode wrote:
> > Note that CUDF strings at the moment do not contain newlines (line
> > continuation are joined together suppressing newlines and leading white
> > spaces). So to structure message we would need some different kind of
> > convention.
> Like for debian/control, line with space and dot. We can use exactly the
> same format as we use for package descriptions.
No, not really, deb822 has a notion of multi-line stanza AFAIR; without
that it would be impossible, for instance, to distinguish between short
and long descriptions. cudf822 does not have anything like to KISS, but
it's not a big deal.
> > Final note (that partly explain my proposal): for most solving
> > techniques, the output I proposed is closer to what they internally
> > have. Having a diff there would mean that they (or an intermediate
> > pipeline component) have to compute the "diff" to generate the output
> > you want. The question is then who should better compute the "diff": the
> > solver or the package manager?
> Creating the diff in the solver would be more efficient for some cases
> where the solver somehow has a diff, but as efficient as computing the
> diff in the package manager if the solver works with the state approach.
> This means it is at least as efficient as computing it in the package
> manager.
Agreed. Still, I believe we really want consensus here, Eugene has
spoken for the "new state" format, and I'm not sure I want to end up
with an initial message of the solver requesting which output it wants.
What is the take of current apt-get/aptitude developers on this?
Would you prefer diff or "new state" approach?
> Just return something similar to the request stanze or several stanzas
> in the form:
>
> package: name
> version: version
> action: <install/remove/upgrade..>
>
> In this case, "action" would give the choice between values like
> install, remove, upgrade (just like the enum I wrote in the other
> message I refered to).
That's a reasonable possibility. Still, I've a few additional remarks
that should be clear *if* we go that way.
The only meaningful action for a CUDF-based diff are install/remove,
upgrade at CUDF level is just a combination of a removal and an install
(the difference is important, as CUDF also supports package managers
where you can install multiple versions of the same package and there
"upgrade" has no clear semantics).
The *order* in which install/remove should be performed is not something
CUDF knows about, i.e. the dependency loop breaking logics is not
currently handled. That will remain in the package manager anyhow. Are
we OK with that?
> > Unfortunately, I'm not familiar with the status of the multiarch spec
> > either. Can someone point us at which impact will multiarch have in
> > terms of dependency solving?
> The thing is specified on https://wiki.ubuntu.com/MultiarchSpec, if you
> want to have a look at it.
OK, will do and get back to that as soon as I'm more knowledgeable on
the topic. In the meantime I suggest we continue considering the
mono-arch case.
> > > Another thing is that there can be two packages with different
> > > dependencies, but the same name and version. I propose an optional id
<snip>
> I just want to know the exact package afterwards, so I can download the
> correct one. And with an ID, I would know which <a,1> to install.
Yep, still the numerical impact / frequency of such cases are important
to understand how to deal with this. If, as I hope, is not the relevant,
I would prefer to handle it by package name mangling which is performed
in the package manager *before* feeding data into the solver.
For instance a package manager can use "a,1" as the first identifier for
package a at version 1 it encounters, and then for the subsequent
"a%id1,1" and so on. Note that this opens a whole lot of problems that
the package manager will need to solve anyhow, e.g.:
- which reference to "a,1" should be rewritten?
- all those in the same package universe?
- all of them using | ?
even considering all "a,1" as equal has problems: which policy do you
use to choose which one in the end you want to install? is that policy
clear to the user?
In fact, I believe this requirement is very ugly, after all we are
trying to build coherent distributions where it is reasonable to expect
package name/versions are unique. The only reasonable case is where the
locally installed package is different from one from the distro with the
same version. But AFAICT current apt-get handles this case by always
reinstalling such a package with the same name/version package from the
archive, which is a reasonable behavior.
> > How often does that happen in practice?
> > How is it currently handled in apt and friends?
> PackageKit uses this one:
> http://www.packagekit.org/gtk-doc/concepts.html#introduction-ideas-packageid
> , but I guess this is also to incomplete for those cases.
Well, in general I believe PackageKit is very naive about a lot
(i.e. too many) issues related to dependency handling, for instance the
whole idea of "we don't need conflicts" looks very naive to me. Anyhow
what that page does not tell is what dependencies mean with respect to
that "packageid". For instance is a dependency on package "a" matched by
all packages called "a" no matter their data?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature