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

Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])



Lars Wirzenius wrote:
> 1. If the upstream source packages are to be included bit-for-bit in their
>    original form, how are you going to unpack them? Remember, you _have_
>    to handle all formats: .zip, .tar.tar, .shar, binhex, multiple files,
>    comp.binaries.* postings, ... That's an awful lot of complexity in the
>    packaging tools.

Oh, maybe my example should have included a Depends: field too in the control
file.  ie. Depends: unzip (>=5.20-3)

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.

The only formats that the source packaging system (sdpkg) would have to
know about are: .upsdeb's and .deb's (which are essentially the same 
thing as .deb files) and possible .src.rpm's.  The source packaging
system would not be responsible for unpacking upstream sources - just
putting them in a standard location so that shell statements inside
the debian/rules makefile would be able to retrieve them and unpack
them.
 
> 2. Unpacking a source package should not require running special programs.
>    This was an important requirement when the current format was designed,
>    and it is an important one. It allows one to unpack safely and portably.

See above.  It's a classic bootstrapping problem.  Since we have
dependencies, why not use them?
    
> 3. It's not reasonable to require that the upstream source (which doesn't
>    change at all) be uploaded for each release. Please don't suggest
>    source packages that consists of a single file. Bandwidth costs money.
>    It's expensive enough to mirror Debian as it is.

I didn't.  Please re-read my proposal (more slowly this time).  :-)

The .upsdeb package would contain the upstream source, which would
only be uploaded once per upstream release.  The .sdeb contains the 
diff's, which might be uploaded quite often.

Look at the number of revisions on some of these packages:
ii  cron            3.0pl1-38
ii  jdk-common      1.0.2-7
ii  libc4           4.6.27-15
ii  libgdbm1        1.7.3-19
ii  man-db          2.3.10-37
ii  mh              6.8.4-12

That means that there is going to be alot of extra downloading to the
developers and the mirror sites if we force them to upload the full
upstream source for every minor revision.  We might lose some 
developers who are only connected through 28.8 modems!

Of course, we could develop a script that sat on the server, and 
dynamically calculated the diff's between what's on the client,
and what's on the server, and only sent that.  But that's more than
what we are currently doing.  Does Red Hat do that?  We should do
that anyways -- but it's added complexity.

Klee favours having a simple .sdeb and no upstream .upsdeb's.  I think
we need to debate this some more.

> 4. Have all packages already been converted to the new scheme? Are we
>    really ready to change everything _again_? Would it not be better
>    to work on, say, being able to compile the whole main distribution
>    with a single command (a.k.a. a single source tree)? Or on bugs; the
>    full list of recent and outstanding reports is over 600 kB!

I think you missed the point -- this system enables a single source
tree.

Also, it would be trivial to convert the current source packages to
.upsdeb's and .sdeb's.

ie.

# sdebconvert jdk_1.0.2-7.diff.gz jdk_1.0.2-7.dsc > jdk_1.0.2-7.sdeb 
# upsdebconvert jdk_1.0.2.orig.tar.gz > jdk_1.0.2-7.upsdeb

No user intervention required.  We could even write a script which 
would convert all of the source packages all at once.

The conversion scripts would be trivial to write, since the scheme
I was proposing is a strict superset of the current scheme.  I
estimate that it would take me a day to write these scripts.
    
>    Incremental improvements might be a better way than revolution, this
>    time.

Actually, I think the scheme I proposed is actually very incremental,
since it's based entirely on the way dpkg handles binary packages.  
Spending effort developing a separate system for handling source
packages, no matter how simple, is probably a waste of time and will
only serve to extend the life of a broken system.

Cheers,

 - Jim







Attachment: pgpjKlEfZWFdO.pgp
Description: PGP signature


Reply to: