Am 20.02.2011 17:02, schrieb Neil Williams:
On Sun, 20 Feb 2011 16:19:49 +0100
Marcus Osdoba<marcus.osd...@googlemail.com> wrote:
Am 20.02.2011 15:41, schrieb Neil Williams:
You are explicitly allowing Sid to be referenced, and in the
bootstrap line too, so this will change your package selection
every time you run the script.
True. But I also declared only two packages (whose versions didn't
change).
Doesn't make much odds - if any dependencies in the set have changed
then apt will not be able to resolve the chain any more. It's unstable,
one thing that is always true is that *somewhere* in the chain,
something has changed. That's enough for apt to bail out.
Ok, but anyway, if one notices, that the package in Sid didn't change
some other "users" would expect that the behaviour won't change at all,
since the depencies remain the same from the package point of view
(still glibc >= same version).
Those packages depend on other packages. Any change in those packages
will force a recalculation of the entire chain and any recalculation
can result in the chain failing to resolve. It is all or nothing -
either the entire chain resolves or the entire chain fails. No
middle-ground, it's true/false, yes/no. Currently, the answer is no;
sorry.
Noticed.
No, probably a change in the versions available in unstable.
Well, no.
Actually yes. That there has been a change is obvious. What is not
clear is where that change occurred.
Noticed. But anyway, when you look at the pacakge version and dependency
page you don't see changes (still the same greater equals for glibc and
so on). I understand, that some update of other packages happened in Sid
(some the desired package relies on), but on the first view at least me,
I wouldn't expect a change in the behaviour. Now I know, that there is
no guarantee.
So the only solution (besides a private reprepo) would be to download
them manually and install them with dpkg via chroot?
No, the solution is a private reprepro. Why are you so opposed to that?
There are two main resons why I don't want to do that.
- everyone else who want's to try out the script set needs to setup a
reprepo (that's the minor one)
- as mentioned earlier, multistrap uses multiple repositories - why not
use it for mix up pacakges from different sources? ; one of the
advantages will go away if I have to setup a whole reprepo - using a
reprepo on my own would lead multiple sources ad absurdum. It's now me
you merges the sources manually - not the tool who is able to do that.
(that's the major one)
So multistrap is as good as apt is. Since apt is not able to resolve the
complex dependencies, multistrap won't either - that's ok, but I wasn't
aware of that.
Temporarily I will implement a method which installs a package manually
before moving to the next step and setting up a "mirror".
Your particular configuration can't work currently - nothing I can do at
this end.
Try to see me as an "experienced" user ;-)
(which means silliest user who runs in every trap)
--
To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d62d7db.8030...@googlemail.com
