Bug#207400: An RPM port of APT
> > > I don't need every change in small chunks, but it would help a great
> > > deal if you could assist me in separating the RPM support from the other
> > > enhancements (such as lua scripting, SWIG, etc.). I've pulled down the
> > > complete diff, but there are a large number of unrelated changes and it
> > > this makes it difficult to follow.
> >
> > It'll be a pleasure to help you in that task. Can you please explain
> > better what code you're classifying as "RPM support" inside the apt-pkg
> > directory? Code inside this directory should be completely unrelated to
> > RPM itself. This code is in apt-pkg/rpm/
>
> There are a number of changes in apt-pkg/ itself (not apt-pkg/rpm) which
> certainly seem to be related to RPM support.
I'll be glad to discuss any changes you find to be bound to rpm only.
> For example, DepCache::CheckDep seems to be mostly replaced, and I presume
> that the two versions are not interchangeable.
They are completely interchangeable. IIRC, many changes there are due to
performance optimizations, since this is the fast path for many
algorithms.
> There is a comment about RPM
> needing to check the dependency type in order to determine if it is
> satisfied.
True, but this doesn't break compatibility with the deb system, as
you'll notice. A different method is used, which falls back to the
old method if not overloaded.
> Also, pkgCache::FindPkg is changed to be case-sensitive. These are
> the kinds of things that I would like to merge in a cleaner way, but
> in some cases the intent is not clear to me.
>
> For FindPkg, it seems logical to add a method to the pkgSystem or
> pkgVersioningSystem to perform package name comparison in a
> system-dependent way.
Very true.
> > Yes. I've looked at this before trying with SWIG. It was quite limited
> > at the time I've looked, perhaps this has changed?
>
> It is still rather limited, but it provides a somewhat more natural Python
> API rather than directly translating the C++ API. If there are things
> missing that you need, I think I would rather add them to python-apt than
> use swig.
I'll look at it more carefully. OTOH, notice that many structures were
carefully implemented, giving them a pythonic look (iterators, etc).
Anyway, Lua is doing most of the job I'd use Python for, so this is not
a priority right now.
> I actually tried the same thing back in 2001, and that seemed to be the
> opinion then:
>
> http://lists.debian.org/deity/2001/deity-200108/msg00030.html
>
> > > I'd like to start with the rpm pkgsystem, along with whatever supporting
> > > code changes it needs in order to not require any #ifdefs in order to
> > > work. Then we can tackle the rest.
> >
> > I think you should go in the oposide direction. Port every interesting
> > feature from the main trunk, and the rpm support will already be there.
> > As far as I know, there's nothing in the current trunk of apt-rpm which
> > couldn't be used as an improvement in the upstream apt.
>
> I do not think this is feasible for several reasons. First, there seem to
> be places where deb support has been broken in common code. These cases
> need to be resolved in a way that allows both rpm and deb to work correctly.
> Also, you have implemented a lot of changes, and I am not familiar with your
> code, so I would be introducing a lot of instability into Debian's apt,
> which I do not think is wise. I would rather merge a piece at a time and
> get everything working well for both of us.
Notice that I haven't suggested that you should do everything at once.
Instead, I've suggested that you should take care of the common part
first, since most of the rpm support is dependent on changes done on
it. Also, I belive that most changes are cosmetic, or lateral, in the
sense that it doesn't change the way apt works.
In a few places, I'd vote for leaving the "#ifdef RPM" alone, like in
these places where package "configuration" is dealt. In the future, we
should move all that stuff to the deb specific backend, but I'd vote to
do that once we have it working. I wouldn't like to do another "partial
merge", like was done before.
> > > Colin Walters and Isaac Jones have implemented repository authentication
> > > (http://monk.debian.net/apt-secure/), which it seems you have as well.
> > > I'd like to merge a unified system for this.
> >
> > This would be nice. Are you able to explain how different it is from our
> > system, and what features you miss? I'd like to be part of the merging
> > process, as we have a good deal of real world experience on this specific
> > area.
>
> I have not done a direct comparison of the two; the URL I gave above
> provides a high-level description of how apt-secure works.
> http://bugs.debian.org/203741 contains discussion on the progress of merging
> this work.
I've just read "How it works" in the URL you mentioned. That's exactly
how our system works. They have even mentioned to be using a "small
part" of our code in the "Authors" section (besides that which was
*already* merged in APT, I belive).
I'd be glad to hear where they differ, and why this is going to be
adopted by Debian instead of the system we have been using for so long
and helping you to integrate it into apt.
----
A big "thank you" for your efforts on bringing this up again Matt!
--
Gustavo Niemeyer
http://niemeyer.net
Reply to: