On So, 2010-08-15 at 11:28 -0700, Steve Langasek wrote: > On Fri, Aug 13, 2010 at 09:31:31PM +0200, Julian Andres Klode wrote: > > Let's keep the APT2 name instead of the UPS name. The UPS name is a good > > joke, but it's not good for a real program name, because: > > > * UPS = Uninterruptible Power Supply > > * UPS = United Parcel Service > > * Ups = a debugger > > * It's a too common name > > > I think that all in all, apt2 is a known name already, it can be found > > easily, it can not be confused with other things. > > Is apt2 using the same resolver as apt, and are changes to that resolver > coordinated with the existing apt implementation? The solvers are not written yet (this needs input from dburrows for the overall API (currently in discussion), and from zack for the external solver; although the latter could be delayed). After all, the goal is to have a clear, documented, understandable and useful code. And APT's solver is a hell to understand in my opinion.
> > Does apt2 implement support for multiarch? The cache can store all information needed for multi-arch, and the API does not really care about it (package objects are <name,architecture,version,hash>, so the difference between two different architectures and two different versions is the same). Some parts for making the API easier to use are missing though, and the multi-arch information is not written yet (as we currently just import the APT cache). > > > Well, you're the only one to complain about the naming. > > I also object to giving this package a name that implies it's the successor > implementation to the current apt when, today, it is not. Some of your > comments suggest that the code isn't even written yet. I don't know why you > would submit an ITP if there's nothing yet to be packaged. Well, in the few hours it had a different name, I considered uploading it to experimental; afterwards, I decided not to waste this bug by closing it, and thus renamed it to the current codename. And I can't play renaming all the time, this would be counter productive to the overall progress. For your information, the code is at http://git.debian.org/?p=users/jak/apt2.git and currently has: * capt (command-line APT); with the following subcommands * Reading: show, showpkg, stats, madison, pkgnames, policy * apt-config replacement: config-dump and config-get * Limited 'why' and 'why-not' * The most advanced pinning implementation for binary packages: * Pinning by source packages works * Regular and glob()-like expressions are supported in Package, Source, and Pin; although slow for the first two. * Completely implemented in 730 lines, where 469 are code; the remaining ones (261) are comments and empty lines. * A test suite In planning and/or development are: * Dropping the APT cache importer and parsing the files ourselves (that's a matter of abstracting things) * Dependency solver * Downloader * Installing stuff (depends on parts of solver) * Support for non-dpkg distributions (Slackware,Fedora,MeeGo) What it shall be / why it is here: * An APT implementation that is easy to understand * An APT implementation that supports other package formats * An APT implementation that is designed for multi-arch from the start * An APT implementation that does not bind apps to the GPL -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281902427.22201.113.ca...@jak-thinkpad
