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