2010/6/26 Luca Bruno <lu...@debian.org>: > David Kalnischkies scrisse: >> The biggest showstoppers are as far as i know that >> a) dpkg doesn't support it >> b) APT doesn't support it >> c) (not many) packages use it (last time i check ~24) >> >> c) is likely caused by a) and b) which in fact decreases the >> motivation for a) and b) to implement it as nobody use it… *** >> dependency loop detected *** > > Goswin recently offered some help to improve the situation regarding a) > and c) points, but I've seen no (public) answer from you: > http://lists.debian.org/debian-devel/2010/04/msg00493.html
What should i have answered? That i like that he wants to work on a) and c)? I knew that as we exchanged a few mails already as he is also present on deity@ and the associated bugreports, so my only semi-public move as response to this mail was to join the recommend list and proceed in doing "stuff" rather than writing the obvious… especially as i was not a (direct) addressee of the mail and got it a bit later than usual. I can't comment on a) as dpkg is magic (for me at least) and the problem for dpkg is more about reference counting for /usr/share/doc files than dependency solving as far as i understand and should as it is promised be done by someone who know his stuff. It might need to do something similar to what i did in APT with creating pseudo-archdepending packages for arch:all packages to "simplify" dependency solving, for their dependency checking but that depends on their liking, isn't limited by compatibility requirements like it is in APT - and the theory is documented in README.MultiArch and code in case i am hit by a bus, so as long as nobody has (further) questions - nothing to comment… c) is also not my cup of tea so far as i never touched a library by now, starting to tell libary maintainers they should do this and that is at least in my understanding a bit awkward then. (This avoids also a bit pre-seeding everyone with my understanding.) ;) > Given that you say apt in experimental is semi-working, it would be > interesting to join forces and see if something almost test-able can > be provided. Semi working as (obviously) nothing can be really installed as dpkg will jump at you if you try. Semi working also as i focused mostly on the case until now that you have e.g. i386 and amd64 packages available but have only packages from one arch installed (fun-fact: It is i386 for me as i have no amd64 system currently). Requesting to install one or two packages from the other arch will be the most seen use case and this works so far, but only with simple constructed cases as in real world you will be hit by c) - i see that positive as this at least guarantees that APT isn't too relaxed about the dependencies. ;) The ABI changes for it are quite stable and i am especially happy that they are API compatible to the SingleArch-epoch. The APT part left is beside bughunting really the (important) MultiArch "auxiliary" stuff i described in the proposal. > If so, it would also be useful to advertise it a bit more and hoping to > gain some momentum... While many would certainly love it, i don't feel like rushing into a mess. We already saw some tries to implement a semi-multiarch behavior and personally i don't want to see them again. Do it once, clean and for real - and at best not before squeeze freeze or even release: It requires a lot of changes to work correctly in a lot of packages and mindsets and would be currently a waste of time which could better be spent in (rc-)bugs and ongoing or waiting transitions. (At least in the eyes of my mentor and myself. Big bangs after releases generally generate more (positive) noise than near freeze time) And most of the auxiliary stuff has the advantage to be not only "needed" for MultiArch, but fixes a lot of bugs in drive-by mode. Thankfully APT has still so many of them to choose from. ;) Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiklo0ach_m9lqo0ekxxxfnudepm6vdk_cyrc...@mail.gmail.com