Bug#203741: Bug#207400: Notes
On Tue, Aug 26, 2003 at 11:40:23PM -0600, Jason Gunthorpe wrote:
> 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..
Thanks for taking the time to look over this stuff again.
> 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.
I'm fairly RPM-ignorant at this level of detail, but I'm going to try to
pick it up so that I can properly evaluate these changes. It seems clear
that some new interfaces will be necessary; if you have any hints on where
they should go, that would be appreciated.
> 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?
Jeff Licquia at Progeny has been kind enough to split up the patches and
file them in the BTS, so this should all be clear very soon. It does not
currently build a separate binary package, and introduces a libssl
dependency in the binary package. This would seem to be nontrivial to fix
because both methods are in the same binary. I think this happened in order
to support redirects from http to https and that sort of thing. Presumably,
this could be changed to use dlopen.
> 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..
I agree, though I wish I had time to keep the bindings up to date.
> 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.
The lua stuff is pretty clearly marked, so I think this can be easily
excluded. One thing that they seem to have done with it is the program in
contrib/apt-files, which does some sort of munging of Contents files.
> 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..
#203741 has some discussion about Colin's patch. I thought it made more
sense to trust anything signed by a key in the trusted keyring, and nag the
user about anything which isn't trusted, rather than specify in sources.list
which sources are secure and which are not. Otherwise, having any unsecured
source in sources.list makes the whole thing insecure. This would
apparently simplify things quite a bit as well. What do you think?
> 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.
Is there any particular advantage to it? There are a lot of checks in
configure.in, but as far as I know, none of them are necessary for modern
Linux distributions.
> 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..
I'm hoping to pick out the stuff that can be merged right away to trim down
the diff, so that the trees can stay closer and common fixes can be shared
at least.
I'm about to leave for vacation and won't be looking at this stuff anymore
until I get back; I'll run down your list then. Thanks again.
--
- mdz
Reply to: