Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
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 <tom@lpsg.demon.co.uk> 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 tom@master.debian.org for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: