David Kalnischkies <kalnischkies+deb...@gmail.com> writes:
>> 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 ?
I can confirm that the problem is a too small mmap. At least now that
I've doubled the value the segfault disapeared as well.
>> 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.
Yeah, I run into the same problem trying to modify dpkg. The problem is
that an arch=all package being installed or not does no longer suffice
to see if it fullfills a dependency. You need to recursively check what
the arch=all package depends on or transitional dummy packages might
break.
I yet have to look at the actual implementation but maybe the pseudo
packages can be made better or the dependencies itself could be changed
to skip the pseudo packages. I don't think guessing what pseudo packages
we don't need/like is going to work well though. Probably better to make
the resolver aware that a psuedo package can be installed or purged
without action and mark it as installed if the depends fit. But I'm just
guessing here from what I read in the README and from skimming the
patch. I need a much deeper look at the source to see if my thoughts
actualy translate into your implementation.
> 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.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
