[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: