[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multistrap does not find squeeze/stable packages anymore

On Sun, 20 Feb 2011 16:02:27 +0000
Neil Williams <codehelp@debian.org> wrote:

> 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:
> > I know, that's why I declared only two packages to be taken from
> > Sid.

It's only those packages (and any dependencies which are different to
the ones in the current archive) which you need to mirror.
> 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.

Stable + testing + private_repo with only specific packages could be
what you need.
> > 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.

(can also be read as "onto an otherwise stable package set" - i.e.
additional packages.)
> > Multistrap is known to use different 
> > apt-sources for building the rootfs.

Yes, but the package dependencies must still be resolvable.

> > 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.

What you need is to take most from stable and take a small number into
a controlled local repository, plus any particular dependencies of those

What you can't necessarily resolve is a mix where the same packages
exist in both. Once you've got two suites with largely the same set of
packages and one is constantly changing versions (unstable), you may
need to explicitly list a lot more packages which you don't actually
need but which need to be obtained from a specific suite. There is no
easy way of identifying this list of extra packages - and the list will
change all the time because you're listing unstable.


Neil Williams

Attachment: pgpjjLGC4xYen.pgp
Description: PGP signature

Reply to: