As I've finally become a Debian developer, the Sourceforge aptitude pages are really mostly useless. In fact, I'd forgotten about them until someone pointed at them in a discussion and claimed that the project was dormant. This is untrue; I've been working heavily on a CVS branch called "ui-rewrite", which will eventually develop into a new aptitude version. I've also released several new versions, which I'll upload to the Sourceforge site in the near future; be aware, however, that the Debian archives are now the official location of aptitude releases, and I want to phase out the Sourceforge stuff. (I'll disable bugtracking momentarily, use bugs.debian.org, and probably only keep CVS, the mailing list, and maybe the homepage around)... read more
I've released 0.0.6.9 . This isn't 0.0.7 because it has an annoying and intractable bug, documented in the release notes and the README. Basically, updating the package lists and installing packages will sometimes crash the program. If you are familiar with C++ programming, it would be great if you could try to find this, especially as I'm short on time at the moment.
This release also adds multilevel undo support and support for actions on package groups.... read more
An apt source for the latest version of aptitude is now available; add the
following to your sources.list:
Ok. After much scrambling around and thrashing of my disk drive, I think I've gotten a new release of aptitude out. I've arranged with Adam Heath to handle the Debian packaging of aptitude in the future (ie, for woody); hopefully he'll sponsor uploads of the package. (thanks Adam!) This release adds a couple of nice features, and also seems to bloat the executable by around 200k (I have a few ideas on how to trim this back without making the structure too inflexible -- in fact, some might actually improve the design, yippee :) )
The only known bug in the current version of the Debian packages is that they might leave /var/state/aptitude behind when you remove them. I'm trying to decide whether this directory should be deleted on any removal of the package, or only when you purge it (and I'm leaning towards the latter) Hopefully I can release a new package soon that addresses this..not sure how this ties in to Sourceforge's release system, though. Maybe I should create another module for debs..
(end incoherent rambling, I'm way too tired..)
I finally spent the 10 seconds necessary to find the information in the CVS documentation about sending commit info to a mailing list. If you're curious about what's going on with the CVS tree of Aptitude, you can subscribe to firstname.lastname@example.org to find out.
Be warned: this has the potential to generate a lot of mail! If there's demand for it, I can create an aptitude-cvs list and just send these messages to that, rather than spamming the main discussion list with them.... read more
I've just tagged and tarred up this release of Aptitude, and as soon as some brokenness in SourceForge clears up (I had to abort my first upload of the file, and now I can't upload a new version) I'll do the actual release.
In case you can't wait to see it, here's the changelog entry for this release:
* "New Year's Resolution" release. I actually managed to fix everything
which I claimed I would, but I've resolved never to promise to fix
something in the next release again. Even to myself. ;-) Also, I want
to release versions more often..... read more
If you've tried 0.0.3 and hate the behavior of the persistent selections -- well, I do too :-) I'm probably going to make the selection part optional in the next release and turn it off by default; it's a nice idea, but I'm sure a lot of people will still want to use apt-get and dselect, and having aptitude fighting with those over whether a package should be installed is simply not acceptable. (the last straw was when it removed nethack because I had installed it using apt-get. No-one touches my nethack! >=) )
Hopefully the APT folks will add something similar to the core libraries so we can share this info with apt-get, capt, and so on. If not, I'll try to find a less invasive way to implement it..