First of all: I hate you, guys! One of my new year resolutions was to keep the bugcount of apt below the bugcount of aptitude. Given that aptitude is only 3 bugs ahead currently i fear i will miss it… and that's your fault!!!111eleven ;)
Seriously, i guess the odds are now against me, but i will at least try to be a good underdog and provide a good fight for the glory of place 4 (and 3) in the list of packages with the highest bugcount… Oh, and given that we properly share a few bugs/features feel free to triage a bit in apt, too, if aptitude reports are boring. ;) (or more likely: you want to reassign something) So a more serious first of all: Welcome in the APT-family! :) On Sun, Jan 15, 2012 at 04:52, Daniel Hartwig <[email protected]> wrote: > * Multiarch > > Aptitude has no support for multiarch setups. > > A certain derivative has already shipped with m-a enabled and they are > receiving a number of bug reports against aptitude concerning this > (apparently no one told their users not to use aptitude + m-a). I was told that it tends to work correctly in many scenarios. (the usual chit chat you know… some of the bugs are properly apts fault, too, as without a released dpkg i never had the chance to try my own code in real world multiarch scenarios, so quiet a few non-trivial bugs were included and properly a few are still in… but heh, who doesn't like busy waiting…) As i said earlier in this thread for the resolver in APT it was the best to reduce the problem with a few tricks to a single architecture problem. I guess this is beneficial for aptitude, too, but i am not good at guessing. Have especially an eye on Provides handling. debian-policy doesn't allow versioned provides (in the sense that they have undefined behavior), but APT allows them! And multiarch makes use of that as M-A: foreign is implemented by provides. Also, as i noticed this week that implicit conflicts need to be relaxed a bit to apply only on real packages, not on virtual ones. Depending on how libapt is used you might be exposed to these kind of "strangeness's" or you are not and these remarks scare the shit out of you… So don't worry too much in case you don't know what i talk about here: MultiArch has a small but step learning curve and not many people really tried it, so you will be one of the few choosen ones. ;) I am properly better at helping/guessing what went wrong if you have a specific example. Feel free to have a look at apt/tests/integration/ the bash scripts include a few simple multiarch tests maybe you can adapt them for your own testing. > Judging by the ongoing effort from the dpkg and apt teams and interest > from other parties, Wheezy is probably going to have m-a support also. Lets hope for the best. > At the very least, aptitude should become aware of multiarch packages > and this means support for libapt-pkg's GrpIterator. > > I plan to get started on this immediately after finishing the few > things I am currently working on (i.e. Real Soon Now) As i said earlier, feel free to bring any problem you might have with it to the attention of [email protected]. In general, if you have something for (package manager) common-interest, feel free to post it there. And/or join irc #debian-apt . Both are pretty low-traffic and not that crowded but "thanks" to the "variety" of maintainers you will find the maintainer of every big and not so big apt-related project in them - so a few seats are already reserved (and preheated) for aptitude crew. :) > * Matching / search pattern handlers > > Not a major issue but there is a lot of room there for, e.g., removing > redundancy. I wrote while working on multiarch an abstraction for the commandline parsing of packages/versions for the apt-* tools supporting tasks as well as regex and selection of specific versions. Back then i thought it would be cool to "backport" at least parts of aptitudes turing-complete(?) search patterns and i still think it might be worthwhile. I just got distracted by other stuff (= i couldn't sell that as a feature required for multiarch) and problems like that i never had used them myself and that they seem to be spread all over the place in aptitude, so if you have any pointers… The code for this abstraction is in apt/apt-pkg/cacheset.cc (see the version in experimental/bzr as i changed to even more heavy template usage). Basically they are containers like std::set<pkgCache::PkgIterator> with a few (static) methods for commandline parsing and stuff. If you think this might be a good idea we can try to make it usable for aptitude, too. Best regards David Kalnischkies _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
