On Sun, 20 Feb 2011 16:19:49 +0100 Marcus Osdoba <marcus.osdoba@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. > > apt is just trying to resolve dependencies. As soon as you mix an > > unstable suite with a stable suite, you can no longer expect > > repeated builds to give you the same results each time. Unstable > > changes all the time, that's why it's unstable. > > I know, that's why I declared only two packages to be taken from Sid. That isn't going to assure you of the same package versions. 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. If you want reproducible results with specific package versions, you either use stable exclusively or you create a static local repository where you control those versions. Debian makes no assurance that any random combination of packages and suites is ever installable, especially once unstable is made part of the mix. Only stable releases have that assurance. Any thing else might work, sometimes; it will fail just as often. That's why it is called unstable. Testing has some level of assurance about such things but even there, transitions can mean that packages have to be removed and reintroduced later. This is why people are working on Constantly Usable Testing (CUT) - there is *NO* prospect of ever managing the same thing for unstable. Utterly impossible. Nothing either apt or multistrap can do about that. > I considered that, but I need to setup a whole reprepo to achive > this. Debpartialmirror didn't work > (http://lists.debian.org/debian-embedded/2011/02/msg00029.html). So use reprepro, as advised in that thread. (debpartial-mirror only failed with that old example file - no way of saying if it would work with a modified file.) > I know. But I also know, that the mentioned package is buggy and I > really want to take it from Sid. Right, so create a repository which brings that version into an otherwise stable package set. > Multistrap is known to use different > apt-sources for building the rootfs. > Some other "users" might also expect that a setup like this should > function: > - take all from stable > - take a small number from unstable if the package from stable is > buggy (if these are not dependant from "too" many others in Sid) No. That is not supportable - when it works, that's OK but there is no guarantee that apt will be able to resolve such a chain. You use such a chain and you have to accept the risk that some days, especially soon after a stable release, it simply will not work. There are frequently uninstallable packages in unstable, that's why it is called unstable. > Maybe this leads to philosophic discussions since you are absolutely > right in NOT mixing up stable and unstable. But I hope you understand > my requirement. Your requirement is to be able to control the packages you use which is entirely dependent on you creating a static repository which contains exactly the versions you need. Multistrap outputs the command offered to apt. You are welcome to try the same command manually and see what can be done to resolve the chain but you're on your own on that one. Dependency resolution isn't easy. > > You were lucky for a while - that kind of luck doesn't last. > > multistrap cannot solve problems like this. Create a stable > > repository containing the mix of packages which you need and you'll > > get stable results. > > > >> Maybe some linkage error after the Squeeze release > > > > 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. > The two packages I include from unstable didn't change! > Of course, I checked that before writing to the list. Who knows what changed? apt was not able to resolve the entire chain, so it fails the entire chain. *Something* changed and that was enough. > So this means, if other packages in Sid change, this has an impact > (at least in my multistrap setup) on those, which didn't change. > One need to know that... Nothing to do with multistrap - apt was not able to resolve the chain. Create the local repository and use edos-distcheck to work out what needs to be changed. > 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? You want reproducible results containing specific versions from specific suites and one of those suites is unstable - your ONLY option for reproducible results is a custom-built repository. Use edos-distcheck to ensure that the packages you want are installable. Your particular configuration can't work currently - nothing I can do at this end. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpZm26q7EE35.pgp
Description: PGP signature