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
