Subject: New package standards - LAST CALL

From: Ian Jackson <[email-masked]>
Date: Sat, 10 Aug 96 00:56 BST

The new source package format has been debated for some time, and I've
now implemented the tools to manage an arrangement which I think meets
our requirements.  There hasn't been much feedback.

The policy manual is little more than a rearrangement and tidying up
of existing documents.  The programmers' manual is mainly
documentation (copied, rewritten and written from scratch) of existing
implementation.

Therefore I propose that unless someone raises a serious problem or
issue within the next week or two the new packaging guidelines as
described in the draft dpkg programmers' manual, the draft Debian
policy manual and as implemented by dpkg 1.3.x, will become official.

After that point package maintainers should install dpkg 1.3.x and
start converting their packages.  Also, after that point any further
changes will involve a change to the Standards-Version number, which
appears as a control field in the new source format, and generate
entries in a changelog.  Thus we'll be able to check which packages
are falling behind.

I hope this meets with everyone's approval.  Bruce, I'd be
grateful if you could let me know whether I have your go-ahead on
this, or whether you think I'm moving too fast.

In case you've forgotten, here are the claimed advantages of the new
source format:
 * Original source kept in the Debian archive, so you don't need to
   download it from somewhere to build a package you haven't built
   before.
 * Better automation of the correspondence between various bits of
   control information, including package names and version numbers.
 * Better and package-independent automation of the creation of source
   packages.
 * Automation of the generation of .changes files from information in
   a parseable changelog and elsewhere.
 * Better ability to record the correspondence between binary and
   source packages in the archive.
 * The possibility of building packages in bulk entirely automatically.

These advantages make it easier for maintainers to take over each
others' packages, and will I hope make the m68k and alpha porters'
lives easier (when completed, at least).

Ian.

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Sat, 10 Aug 1996 15:47:40 +0200 (MET DST)

> our requirements.  There hasn't been much feedback.

That's probably because a lot of people aren't listening. Alas. I've
almost ported all of base (and gcc, and binutils-2.7, etc) to the Alpha
architecture and about 50% of the base packages doesn't even have
Architecture: support. So I'd say unless someone objects, go for it.
The main reason I haven't commented is that it actually looks very good
to me, apart from one thing that I've one now though of (see below).

I also think that when you make the new source package official, we
should warn all maintainers of the base packages and ask them to convert
their packages to the new standard. If they don't react in say 2 weeks,
someone else can do it (I'll take some) like David did during the
transition from a.out to ELF.

[advantages deleted]
> lives easier (when completed, at least).

Well, one other idea. Since the original source and the patch are kept
in the archive, would it be possible to look for an additional architecture
dependant patch? For example, if you have

bash-1.14.6-1.dsc
bash-1.14.6-1.EXTRA.alpha.diff.gz

and you're compiling under the alpha architecture the extra diff will be
added automatically? It would be a tremendous advantage when porting to
a new architecture - the porter need only supply the extra patch to the
debian archive and it will "just work". Also, the patch will be in a public
place so that the original maintainer can integrate the patch in the
next version of the package.

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:[email-masked]          http://www.cistron.nl/
[email-masked] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

---

From: Ian Jackson <[email-masked]>
Date: Sat, 10 Aug 96 17:13 BST

Miquel van Smoorenburg writes ("Re: New package standards - LAST CALL"):
...
> transition from a.out to ELF.

Yes.  If a few people do a lot of packages it's probably quicker and
less error-prone, anyway, then having the maintainers do it
themselves.  On the other hand having the maintainers do it themselves
will get them to learn the ropes ...

...
> dependant patch?  [...]

No.  Any architecture dependencies should be avoided; if they can't
they should be dealt with at build-time in the package itself, rather
than by making several versions of the package.

> [..]  It would be a tremendous advantage when porting to

The porter should make an architecture-independent patch (ie, one that
will work on any architecture) and then either:
 (a) add `.1' to the Debian revision and release a new source package
     with their binaries - they should send the patch to the original
     maintainer for inclusion, too;
or
 (a) send the patch to the main maintainer (or to maintonly@bugs) and
     wait for it to be included.

Ian.

---

From: Michael Alan Dorman <[email-masked]>
Date: Tue, 13 Aug 1996 14:25:17 -0400

>policy manual and as implemented by dpkg 1.3.x, will become official.

I hate to even ask this, since if we want to make this change for the
next release, but can we have just a bit more time?

I have been singularly busy of late, and have only recently gotten to
the point of being able to read the new docs you put up, and while
everything seems sensible "on paper", I worry that it we don't have
people actually try it out, there's going to be some unexpected
problems.

>   a parseable changelog and elsewhere.

I have installed the changelog macros, and find they work well.

Finally, though you say the documents are just cut-n-paste from other
stuff, they seem to do a better job of documenting some of the
"conventions" that we've adopted over the last several months, WRT
shared libraryies and the rest.

And if you're creating them from your linuxdoc-sgml hack, I'm quite
interested that you make it available for others use.  It seems much
cleaner than the original.  Or maybe that's just a function of a
better conversion tool.

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."

---

From: Ian Jackson <[email-masked]>
Date: Wed, 21 Aug 96 23:59 BST

> people actually try it out, there's going to be some unexpected

I've tried very hard to leave hooks all over the place, especially in
the parts where the new scheme is more automatic than the old.

It won't be a disaster if we don't get everything converted.

> I have installed the changelog macros, and find they work well.

Thanks.

> shared libraryies and the rest.

Good.

> cleaner than the original.  Or maybe that's just a function of a

:-).  The better conversion tool helps.  But having a DTD that only
describes things that are actually implemented helps too.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 23 Aug 96 04:15 BST

Otmar Lendl writes in private email which I'm sure he won't mind me
posting:
...
> What I would appreciate is, that all the Developer Ressources
> (Guidelines, Hints, Virtual Names, FSSTD & co.) have a central
> WWW page where I can easily look up the currently valid standards.
> 
> Could you please arrange something like that ? It makes life a
> LOT easier for part-time packagers.

I think this would be a good idea.  We already have a central FTP
area, so it may be just a matter of writing the HTML page and making
the dpkg SGML documentation available.

What do I need to do to make the dpkg SGML documentation available ?
I can cause releases of the dpkg package to upload formatted versions
of the manual, but how should I package these for shipment ?  The HTML
versions in particular come in many files ...

Ian.