On Sun, 11 May 1997, Jim Pick wrote: > The point I was trying to make was that having dependencies on > binary packages would be really, really nice.
This gets more complicated. To allow for cross-compiling or bootstrapping, some packages need to be compilable using the Source from another package, so eg:- SrcPackage: xmp Depends: awe-drv | src.awe > > > 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 totally agree. RPM's way _is_ broken. > > > 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. IMHO this is where we need the possibility of dependencies on Source or Binary packages. Also a standardized "build lab" (build-i386.debian.org, etc.) being enforced would be a really nice way of ensuring a self-consistent distribution. But I'm not sure if we have the resources to do that. > > 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... :-) We should be planning this for Debian 2.0. The release of that will have lots of nice new features (deity for one). > > > 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. Preferably sooner. It would be really nice if deity could handle *source* packages :>. But its getting designed pretty quickly, and might not be flexible enough by the time the new source stuff gets done. > 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. dselect/deity and this are basically part of the same overall problem - the packaging and distribution system needs a bit of an overhaul. -- Tom Lees <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
