> Jim Pick: > > That way, the unzip package would have to be installed before you could > > use the package. Elegant, eh? And it's already implemented inside > > dpkg. > > I don't think so. The point of keeping an unmodified copy of the > upstream sources is to increase security by allowing PGP-signatures > and whatnot to work. If you then run random, unknown programs to unpack > the package, you're throwing away any security gained, and more. You > also make it unnecessarily difficult to unpack source packages on > non-Debian systems. > > The upstream PGP-signatures needs to be solved in another way. I think I need to clarify again. I've basically dropped the idea of having a "srcpostinst" that would modify a source package when doing a dpkg -i "source package". But the idea of having dependencies on other source packages, as well as binary packages, is quite important. There may be programs that the debian/rules makefile requires in order to build a package. We can insure that those programs (for example, debmake) are installed before running "debian/rules binary" or any other scripts inside the package. I am no longer advocating having scripts in the source package that automatically run when it is installed. The point I was trying to make was that having dependencies on binary packages would be really, really nice. > This is what I'm quite determined to avoid. I do _not_ want to > depend on Debian maintainers being infallible and non-malicious, > at least not so much that I can't even unpack a Debian source > package without endangering my system. > > If Red Hat does this, they're broken. Ok. Let's forget I ever mentioned it. This little flaw in my initial proposal is detracting from the overall idea. I give up. > > Klee favours having a simple .sdeb and no upstream .upsdeb's. I think > > we need to debate this some more. > > Well, my mind's decided. Bandwidth costs, cross-Atlantic especially, > and the trivial inconvenience of having three files instead of one > is very well worth it in real money. I basically agree with this. But I'm going to keep an open mind, until I see more debate. > > I think you missed the point -- this system enables a single source > > tree. > > The current system can be a single tree as well (put all source > packages in one directory, and do a loop with "dpkg-source -x", > and "dpkg-buildpackage -rsudo -uc -us"), but both systems are > pretty far from the BSD source tree, I think. Unfortunately, with the current state of the source tree, this doesn't really work. It's way too easy to build source packages that don't unpack with dpkg-source -x. I've seen way too many packages for my liking that won't build out of the box. Many of them depend on specialized environments that only exist on the original maintainers machines. > But that's beside my point -- there's so much other work to > do at the moment that I don't think big changes the source > packaging format at this point will improve things. There's always too much to do... :-) > > Actually, I think the scheme I proposed is actually very incremental, > > It would change all source package file formats, and all tools > relevant to source packaging, and would require our developers > to learn to deal with a third source packaging format. A bit > too much of an increment for me. :-) I agree that the current source packaging system works, but it is broken in many ways. So we're going to have to fix it sooner or later. If we wait until later, there's going to be even more of an installed base of tools and packages that are going to need to be changed. So my personal preference is to spend some time up front to get our act in order. Right now, this ranks #2 on my list of things Debian has to fix -- dselect/diety is #1. Anyways, thanks for commenting on my corny proposal... :-) Cheers, - Jim
Attachment:
pgpvjGPWVP2Zs.pgp
Description: PGP signature