apt-rpm roadmap
Dag Wieers
dag at wieers.com
Wed Apr 26 09:40:24 PDT 2006
On Wed, 26 Apr 2006, Panu Matilainen wrote:
> Just some food for thought - here are some things I have in mind for
> apt-rpm future. The only thing set in stone is that I want to have a
> bugfix release in a reasonably short timeframe because it's inevitable
> that there are some issues lurking in all the new code from repomd and
> multilib support (some already found and fixed, surely there are others
> still). Everything else is debatable :)
>
> Short-term:
> * A bugfix release - lorg3.1:
> - fix any remaining bugs found in repomd, make the code more rebust
> - fix any remaining bugs found, caused by repomd changes
> - fix serious compiler warnings (such as type-punning warnings
> from old rpm header handling)
> * get Synaptic working properly
>
> Mid-term
> * Next "new feature"-release:
> - review and merge useful patches from altlinux apt
> - review and merge useful bits from debian-apt 0.6.x if any
> - make repository pinning work with repomd [1]
> - improved apt-cache viewing (just compare 'yum list' and
> 'apt-cache pkgnames') and other misc "cosmetical" things
> - continued code cleanup
> - see if there are any low-hanging fruits for optimizing repomd
>
> Long-term (lorg5 and beyond):
> * Introduce proper repository configuration into apt
> - per-repo settings such as signature checking, proxy config...
> - mirror handling
> - easy runtime switching of enabled/disabled repositories
> - cannot be sanely done with sources.list format - going to be a big
> hassle wrt Synaptic and other apt-based software!
> * Integrated package signature checking (auto-import based on repo setup
> etc)
> * Stop munging downloaded package names, download cache reorganization
> * Investigate further optimization possibilities especially with repomd
> (midlevel caches etc)
> * Drop support for ancient rpm versions to get rid of LOTS of #ifdef's
> and ugly code, make better use of the "new" rpmlib API
> * Continued general code cleanups
> * Reformat the whole codebase for readability + consistency?
> * Work with libapt-front folks for better APT API
> - make it work with apt-rpm
> - make sure it takes rpm's requirements into account
> - help design + implement the API
>
> I'm pretty sure I've forgotten some things from here I've had in mind
> and things already discussed with other people (more or less in
> private), please fill in and feel free to comment, add new ideas etc.
Here's my current wishlist :)
+ Easier pinning support (more simple syntax with added functionality)
+ Mapping between signature(s) and repositories and pinning based on
signature
+ Like smart the option to update when doing upgrade or install
eg. apt-get --update upgrade
+ Delaying dropping older rpm releases as late as possible :)
apt is currently the only solution that stretches (almost) from EL2.1
(+- RH7.2) to FC5. Smart and Yum fall short. Even on EL3 Smart doesn't
work and Yum is different (different options and functionality).
And EL3 will be around a long time still.
Thanks a lot for continuing development !
PS Somehow it made a big difference to the Debian colleagues that the
systems were 'managed' by Apt :)
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
More information about the Apt-Rpm
mailing list