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

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



>  Why aren't sources packed into a single archive, the way rpms files
> are?

I think the reasoning is that each debian-revision consists of only 
small changes and patches to the upstream sources, so why re-upload 
the upstream sources.

Personally, I think the whole Debian source packaging scheme needs
a major overhaul.  Too often, the .orig.tar.gz part of the package
gets separated from the .dsc and .diff.gz parts.  

Plus, the naming convention of the .orig.tar.gz part requires ripping 
apart the original upstream tarball and renaming everything.  This 
means that if the .orig.tar.gz file gets lost (one package I took
over is in this situation), it's almost impossible to retrieve the 
upstream version, rename everything exactly as the original
maintainer did, repack it, and have the same md5sum checksum.  

Of course, this also means we cannot implement a automated system where 
we can check the .orig.tar.gz files in our source distribution against
the upstream source distributions (located on well known web sites).
And forget implementing a system where upstream developers PGP sign
the checksums of their packages.  Our current source packaging scheme
works mostly -- but in the long run it is going to open us up to
being infiltrated by "trojans".

Instead of having one type of source package, we should have two
different types:

Upstream source package (.upsdeb?):
  - contains original "tarballs", patches, etc. in pristine format,
    not renamed or anything
  - control file lists files, renamed name, description, upstream
    contacts, debian maintainer, section, etc.
  - pgp signatures/checksums (if available)  
  - list of URL's (ftp and http) where pristine sources are 
    available - include multiple locations if possible
  - LSM entries

Debian source package (.sdeb?):
  - contains equivalent of .diff.gz and .dsc
  - control files
      - can depend on multiple upstream source packages
      - can depend on having certain .deb's installed on
        maintainers system
      - fields currently in .dsc file
      - list of .deb files generated (can generate multiple .debs)
  - files in /debian directory (not patches)
  - patches for upstream source packages
  - debug directory to store alternate libraries with debugging
    information linked in + debugging symbols and links.  This 
    way we could hack together some scripts that would enable
    anybody to start a debugging system on any Debian-based
    executable on the system, and the appropriate source package,
    debugging symbols, and source files could be pulled in off
    the Internet automatically.

Debian binary package (.deb):
  - control file lists .sdeb which generated it

In the source archive, the .upsdeb packages could be stored
in a separate directory "/upstream" below the directories where
.sdeb packages are stored.

ie.

/hamm/non-free/binary-i386/devel/jdk1.1-runtime_1.1.1-5.deb
/hamm/non-free/binary-i386/devel/jdk1.1-dev_1.1.1-5.deb
/hamm/non-free/binary-i386/docs/jdk1.1-docs_1.1.1-5.deb
/hamm/non-free/source/devel/jdk1.1_1.1.1-5.sdeb
/hamm/non-free/source/devel/upstream/jdk1.1_1.1.1.upsdeb

The .deb, .sdeb, and .upsdeb could all maintain the same basic
format (ie. an ar file, with a control.tar.gz section, and
a data.tar.gz section).

Comments?

Cheers,

 - Jim




Attachment: pgphSu5g3KBj2.pgp
Description: PGP signature


Reply to: