Bug#536029: support to download index files for multiple architectures
Hi Goswin von Brederlow,
2010/4/16 Goswin von Brederlow <goswin-v-b@web.de>:
> deb [arch=amd64,i386] http://chocos/debian sid main contrib non-free
>
> E: Malformed line 1 in source list /etc/apt/sources.list ([http://chocos/debian] is not an assignment)
>
> It seems that there must be an explicit space after [ and before ].
Looks like the whitespace skipping is done in the wrong way as the
error message is an option field specific one…
> 2) Missing the information for which architecture a Packages file is:
> Get:3 http://ftp.de.debian.org sid/main Packages [6574kB]
Strange intended, they are shown for the downloaded packages and in the
policy but not in "update"…
> 3) Segfaults if an architecture is excluded
> APT::Architectures={ "amd64";"i386";"armel"; };
> deb [ arch=amd64,i386 ] http://chocos/debian sid main contrib non-free
Worked fine for me. (TM)
My local repository has no amd64 so i excluded that right from the start
so i am pretty sure this should work.
It is properly a too small mmap (but the error should be shown… :/ )
Could you provide complete source.list / config ?
> 4) Oldy but goody: E: Dynamic MMap ran out of room. Please increase the size of APT::Cache-Limit. Current value: 50331648. (man 5 apt.conf)
Yeah, we haven't raise the limit as we doesn't support multiarch
currently anyway
and the mmap doesn't support growing currently (i hope i can work on that)
so to whatever value we raise this amount of memory need to be free as it is
allocated at once which isn't to gentle for small devices if the value
is too high.
> I guess all the extra dummy packages for arch=all flood the mmap so
> again it must be increased.
The real flood is the pure mass of "implicit" dependencies added for
every package version. (see apt-cache stats and the FinishCache() method
in pkgcachegen.cc) As written in the README file the complete
MultiArch implementation is currently done without (much) changes to
the resolver but instead handled by Dependencies - done in the hope that
resolvers doesn't need to be told about MultiArch (or at least not in first
iteration).
> I'm not sure the dummy arch=all packages is the right approach for multiarch.
The Spec says that arch all packages should be handled in the same way as
if they would be of the same arch as the package which depends on them.
( Dependencies involving Architecture: all packages )
This nearly forced me to split the arch all packages into arch-depended
pseudo packages so other packages can depend on them instead -
otherwise APT wouldn't be able to calculate the status of the dependencies
in advanced…
Another point is that packages from time to time switch their "Architecture"
(from any to all or vice versa) which can be transparently handled this way.
What i really dislike is the MultiArchKiller (nickname for the operation done in
depcache.cc in Update() to remove pseudo packages for architectures we
don't need/like to have this package installed [in cache generation an
all package
is installed means all pseudo packages are installed - which we need to revert
now in a clever way]) as it is a lot of guesswork and (therefore) full of bugs
(the last fix is in my branch rev. 1969), but i so far see no alternative as i
could still install e.g. with dpkg or others non extended updaters so using an
extended_state is out of question.
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
P.S.: Sorry, the message is not well-prepared (i don't even have the source)
and doesn't include much details/answers, but i want to answer now non the
less as i am not available in the next few days for comments.
Reply to: