apt-rpm roadmap

[Gary Greene]

On Wednesday 26 April 2006 11:59 am, 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

Glad to see this on the map, as this is necessary for getting Adept ported to 
RPM platforms. Adept would greatly enhance apt-rpm on KDE based platforms, 
and the only way it'll make it on to them is to have libapt-front. :)

> 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.
>

-- 
Gary L. Greene, Jr.
Sent from uriel.tolharadys.net
 13:03:05 up 12 days,  1:00,  2 users,  load average: 0.23, 0.08, 0.07

============================================================
Developer and Project Lead for PhoeNUX OS.
 check out http://www.phoenuxos.com/ for more info.
EMAIL : greeneg at phoenuxos.com
============================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20060426/5727f287/attachment-0003.pgp>