Bug#207400: Notes
On Tue, 26 Aug 2003, Matt Zimmerman wrote:
> Here is an initial list of the stuff in Conectiva's tree which is not in
> Debian's. Some of these are probably not suitable for Debian, at least at
> this time, and the rest need to be broken up in order to merge. Note that
> there were some things whose purpose wasn't clear to me, and this list could
> probably be coalesced into a smaller number of higher-level changes, but
> this is difficult to pick out with a monolithic patch of some 100k lines.
So, I'll chime in here..
I belive in the past I've looked at all these patches, at least in some
earlier form, and there are reasons things are as they are..
The stuff to handle RPM version+naming+dependencies has developed alot of
regressions since I merged the earlier passes. This is hard to fix because
you need to see the whole picture of how and why DEB and RPM deviate from
each other so that you don't introduce a regression into either side. It's
also a little tricky to know where to put all the necessary new
interfaces.
SSL stuff from Progeny/etc: I was more or less happy with the last patch I
saw, my biggest concern was the shear amount of extra goo that had to be
directly copied from some ssl sample program to make it work. I don't
recall if the work was done to make a seperate binary package for the SSL
stuff or if that even makes sense anymore.
I'm not sure what the other 3 items in Progreny's patch are?
SWIG: I never liked the idea of the SWIG markup in the code. Since Gustavo
has said that the SWIG authors will not accept the patch I'd drop it. It
also sounds like the python-apt painfully hand crafted bindings are
nicer..
lua: It looked neat, but I never understood what Connectiva was doing with
it. APT's operation is already very complicated, I worry that adding
strage arbitary user scripting will only make it hard to understand bug
reports.
Signed Repos: Parts of this exist in all sorts of forms.. Colin's
solution seems closer to what I think is needed than Connectiva's - in
that it does everything in a single download pass. This is harder but has
a faster runtime. The patch Colin just sent seems pretty close, but I only
looked briefly. It looks similar to the last patch I saw which did have
some problems. Since this is a security thing it has to be inspected and
any holes that could result in an unsecured file being used must be fixed.
Otherwise you are just deluding yourself if you think there is any
security..
Connectiva Build System: Gustavo did this because he hated my original one
:> Unfortunately in the process a number of things that are important for
Debian got striped out. It would be a big job to merge this and restore
all the lost functionality.
I just ran through the connectiva diff of only the apt-pkg directory. Lots
can just be blindly merged. Lots needs more thought and there is a bunch
of stuff that doesn't look quite right..
Some pointers -- be warned to take what I saw with some salt as I
did not spend too long determining. Note that when I say something is
fine it just means the intent of the diff is OK. The actual text may
still need reformatting to, for instance, remove CNC comments, fix
indenting or tidy up #if 0's. Keep an eye on things that just make
apt-rpm work as opposed to things that change/augment/etc
apt behaviors. You can merge all of the former but in the Debian source
tree the behavior should be _consistent_, even if the RPM guys hate it :>
- acquire-item - This is all the secured repository stuff. Figure
it out seperately.
- IsCritical->IsImportant... The Critical/Important differentiation
never seems to have panned out. The distinction was ment to allow a
policy routine to manage things like suggests. If connectiva says
removing it makes things much faster then might as well, but remove
_all_ traces of IsImportant.
- algorithims.cc - This one is hard.
RemoveDepends looks fine, assuming it's algorithm is correct (bet it is)
Obsoleted fix to distUpgrade is harmless on debian since we never
use Obsoletes. Though perhaps a function is needed here.
Various changes to the resolver.. I know Gustavo/etc tested these
and found them to fix problems. Even when I remembered everything
it was beyond me to be sure they didn't cause problems in Debian.
I fear this routine, it's impossible to test.
I would put them in a debian release..
- New VS->CheckDep: I had an objection to this, but I think it has been
trounced by some 'new' discoveries about RPM behavior. I would take
all these changes and ensure the Deb routines are updated to export
this new interface.
- I don't get the point of these, and I'm not sure it makes any
sense for them to be RPM specific. I belive apt-rpm will work
without them:
_system->IgnoreDep
_system->ProcessCache
- depcache.cc
- Faster checkdep. I didn't look too hard at this but it looks
like it is functionally identical. No problems if it is
- Obsoletes stuff is safe since we never set it.
- State stuff - I have no idea what this is for, or
if it is right. Does APT-RPM have performance problems building
the dep cache? I know really really slow system chunk along
here (my 73MHz ARM box is painfull for instance).
- depcache.h
- GetPkgPriority: I didn't track this down, I forget right
- indexfile.h
- GetReleases: Part of the security stuff
- packagemanger.cc
- So again this is obsoletes which we don't use. I belive
the point of this is to make RPM's installer work but I'm not
sure it is correct for 100% of cases, the reasons are probably
similar to why we don't use the dpkg automatic removal on replaces.
You may be able to omit it and have a working apt-rpm.
- Clearly the #if 0's are not going to result in joy for Debian.
- pkgcache.cc/.h
- All this is optimizations and I think it is fine.
- mergelist.cc
- This reinstall thing sounds like a nasty hack. I don't know what
it is for. I wonder if the policy engine is not a better way to
resolve it?
- orderedoffset stuff.. I think Gustavo's method is just better..
The whole OrderedOffset should go and the Deb stuff should
implement List.offset() and the proper kind of progress
pre-configuration to make that work too.
- Arch stuff -> Eep. Donno how this will fit into future deb
directions
- IsDatabase Hack on 'end of same version set': This undoes
a specific design goal. It 'fixes' the well known problem of apt
wanting to keep installing a locally compiled package of the
same version, at the cost of never being able to install the
remote version..
- strcmp? This looks like a bugfix as the routine it is in
doesn't get used by debian.
- Optimizations in newpackage seem fine
- All the fileprovides stuff is unused in debian. It looks a little
odd to me but I haven't looked close enough. It would be nice
if it could rely on the detection of file provides in the
scan instead of the generator flag so RPM systems with sane
packaging don't have to pay this _huge_ penalty. Some lines
appear to need if's around them.
- pkgrecords.cc - This fixes a segfault if you free things
out of order, it's harmless.
- pkgsystem - ProcessCache, IgnoreDep have been spoken too,
CacheBuilt make me queezy, I'd rather the system instance didn't
have that sort of 'global', but that looks hard to fix.
- policy.cc - I didn't look at the use of GetPkgPriority.. I'm
surprised this is needed.
- Version.h - I'm not sure how the arch stuff will
interact with whatever debain does.
So that should get you down to maybe a couple hundred lines of diff in the
apt-pkg directory which is a good part of the battle to just _having_ RPM
support.
The features Connectiva has elsewhere are interesting and should be looked
at of course.
Jason
Reply to: