[ dropping dose-devel as it allows posting only to subscribers, sorry
about that ]
On Sat, Nov 09, 2013 at 01:58:09PM +0100, David Kalnischkies wrote:
> I had commented some parts on IRC before this series. Maybe they were
> lost in transit, so let me repeat them …
If they've been lost in transit that has been an overlook. Before
submission here the patches went through various iterations, taking into
account your comments. Maybe we just need a few more iterations :)
> > + if (_config->Exists("Commandline::AsString") == true)
> > + fprintf(output, "Command-Line: %s\n",
> > + _config->Find("Commandline::AsString").c_str());
> > +
>
> I think I know why you want that, but I don't think its a good idea.
>
> You want to know for which packages the user has chosen a specific
> version vs. for which packages the solver is "free" to choose one,
> right? (assuming there is actually a well defined difference)
That's correct, yes. More generally, the problem is one we've debated
before and for which I think we don't have (yet?) a decent solution:
there is no first-class notion of "user specification" in the APT code
base. Once the command line is interpreted, it gets "compiled" to pin
values, and it's subsequently hard to distinguish what the user
requested right now, as opposed to other inherited pin values.
> Extracting this from the command line will become horrible very very
> soon.
I agree. And I understand that you would like to avoid that solves shot
themselves in the foot. But I think we have a choice here, between
leaving the solvers completely in the dark about what packages the user
requested, and trying to do their best peaking at the cmdline.
Note that this is already happening. Not via APT itself, but via the
/usr/bin/apt-cudf-get wrapper which is shipped as part of apt-cudf.
Currently we basically say "if you are fine with the solver not knowing,
use apt-get --solver; if you want the solver to know more about your
intentions, use apt-cudf-get". I think that knowledge is really needed
to allow external solvers to a decent job.
Now, of course we're not supporting all of the APT cmdline
expressivity. Just the basics, i.e.: pkg, pkg/suite, pkg=version, no
regexps nor globs. Of course the support could be extended, or we can
just spot unknown syntaxes and say "sorry, that is not supported".
FWIW, I hate myself having to parse the cmdline once again in a
different place :-) If there is a better way to pass on user request,
more structured, I'd love to hear about that.
Do you think that the risks of using the cmdline (as a string) outweigh
the benefits of allowing external solvers to do a better job in
respecting user desires in, say 90% of the use cases out there? I
personally don't, hence I'm hereby insisting to pass the cmdling onto
external solvers. But, obviously, I'll respect your decision.
> > + if ((File->Flags & pkgCache::Flag::NotSource) != pkgCache::Flag::NotSource)
> > + Releases.insert(File.RelStr());
>
> Have you tested this with (flat) archives without a Release file?
> I have the feeling that those return an empty string, which is probably
> going to confuse EDSP readers. Maybe don't insert empty strings into
> Releases set and don't print 'APT-Release:' if Releases is empty.
Nice catch. I'll give a stab at implementing this (as soon as
git.debian.org is back...)
Cheers.
--
Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature