Subject: Source packaging

From: Ian Jackson <[email-masked]>
Date: Thu, 4 Jul 96 15:49 BST

(BTW, one objective that I forgot to mention in my last mail is to
have something better-integrated with our upload handling mechanism.)

I'm leaning towards the `3 separate files' approach - a .tar.gz of the
original source, named <pkg>_<orgver>-<rev>.orig.tar.gz and unpacking
into <pkg>-<orgver>/ (note hyphen), a .diff.gz containing the
debianisation patch, named <pkg>_<orgver>-<rev>.diff.gz, and a control
file <pkg>_<orgver>-<rev>.dsc (optionally PGP-signed).

I don't have personal experience of this, but people are saying that
it will be hard to maintain accurate dependencies for source packages,
and this seems likely to be true.  I think we should either make this
a requirement, or not, and it seems to me that we should leave it for
now but leave the option open of doing it later.

So, my current list of fields for the control file is:
 Source: <source-package-name>
 Version: <orgver>-<rev>
 Architecture: <"any"|"all"|architecture>
 Generates: <binary-package> [, <binary-package> ...]
 Maintainer: <maintainer's name and email address>
 Data-MD5sums:
  <md5-checksum>  <pkg>_<orgver>-<rev>.diff.gz
  <md5-checksum>  <pkg>_<orgver>.orig.tar.gz

The Generates line would perhaps be optional, with a default of a
single binary package named the same as the source.

I'm unsure about the Version field, mainly because of the problems it
is may cause with respect to updating and repacking packages.

We'll need a couple of new required files in the debianised source:

 debian.sourceinfo

  The Source, Architecture, Generates, Maintainer and perhaps
  Version fields to be included in the .dsc file.  The dpkg-source
  script would read this when it built a source package.

 debian.Changelog

  The Debian changelog for the package.  This will be used by my new
  dchanges-a-like for getting changes info for the .changes file.

 debian.changestemplate

  The .changes file with special markers where the variable
  information goes.  It needs to have at least the Files section from
  the .changes file in some funky format, so that the sections and
  priorities can be set.  We need a flag for each file that says
  whether it is arch-independent - see below.  The Format, Date,
  Distribution, Source, Binary, Architecture, Version, Maintainer,
  Description and Changes fields can be derived from the .deb and .dsc
  files and the debian.Changelog.

The debian.rules source and diff targets become obsolete, because the
debian.sourceinfo file contains all the info you need.

Then, to rebuild a package for a new architecture you unpack the
source (dpkg-source will make the debian.rules executable for you),
run debian.rules build, as root debian.rules binary, use the new
dchanges-a-like with the `arch-dependent files only' option and the
`read changes information from here' option to generate the .changes
file, PGP sign the .changes file and upload the result.  We can
produce a script to do all of these things.

To take over a package or release a bugfixed version you unpack the
source and play around with it, and then carry on as if you were the
maintainer:

To release a new version you make sure that the debian.Changelog has a
new entry for your modifications, giving the distribution and version
number for the changes file in one of a few standard formats.  If the
.dsc file has a Version number the .sourceinfo probably will have to
too, so you have to update that as well.  Alternatively, we might be
able to provide a script to extract the most recent version number
from the debian.Changelog and optionally update any timestamp that's
in it or add a `package released' change entry, depending on the
format.  Then the .sourceinfo could leave out the version, and the
debian.rules could use it for substituting into the debian.control
files.  Anyway, you run debian.rules clean (perhaps as root), use
dpkg-source to package up the new source, and then debian.rules build,
binary (as root), and use the new dchanges-a-like to generate the full
.changes file, extracting the changes info from the Changelog.
Neither the dchanges-a-like nor dpkg-source PGP-sign the files they
generate.

Questions:
 * debian.Changelog format ?  I have one, but lots of people use
   Emacs's awful ChangeLog mode.  Someone who understands Emacs will
   have to either write a new mode for debian.Changelog files, or tell
   me what format to expect and users how to represent the required
   information, or both.
 * What about all this stuff to do with Versions ?
 * Comments ?

Ian.

---

From: Juergen Menden <[email-masked]>
Date: Fri, 5 Jul 1996 11:14:29 +0200 (MET DST)

On Thu, 4 Jul 1996, Ian Jackson wrote:
> original source, [...] a .diff.gz containing the
> debianisation patch and a control

> [...]
> we should leave it for

sounds reasonable.

>  [...]

i'm not sure if we should include this field, at least for 
the moment. there are only very few packages which do not 
make any sense on eg m68k. most packages will even compile
without further notice for different architectures. 

the distinction between all and any: this at least should be
skipped. the source description should only mention whether
(using that sources) binaries can be build on some architecture, 
but not, on which architectures the resulting binaries are 
usable. this is the aim of the control file in the binary
package. 

another point is, that the information which the field 
supplies on binary pachages (all vs any) is only partly 
usable. think of eg ncurses, which builds the shared libs
in one binary package (arch-dependent) and the terminfo
files in another package (arch-independent). the architecture
field in the dsc file should say: buildable on all architectures,
but the binaries are not for all architectures, which is only
partly correct.

third point: sorry, i have forgotten what semantics you
have chosen for all, and which for any. as i cannot deduce
it from the word, this might be confusing evtl even for others. :-))

>   script would read this when it built a source package.

ok. the version field should be in the debian.ChangeLog.

>  debian.Changelog

right

>  debian.changestemplate

not needed. all information can be taken from the control,
the sourceinfo and the debian.Changelog. these files should
be used!

but: the debian.control files need some revisiting. 
[from now on, all field names i talk of are the ones in
the control files for the binary packages]. 

these files should only contain the information which 
is unique for the the binary package, and which can not 
be gathered otherwise. these are:
   Description:
   Depends: Recomends: Suggests:
   Conflicts: Replaces: 
evtl Provides: (what does this field mean?)

all other information should not be contained in that
file(s). a script
  dpkg-mk-control [options] [control file name]
builds the control file.

usage: if no control file name is given: use dpkg.control
  options (defaults in brackets): 
  -a arch:  The architecture of the binary 
            (dpkg --print-architecture)
  -o path:  output the control file in path/DEBIAN/control
            (./dpkg-tmp)
  -p package name:  Package name (take from debian.sourceinfo)

Priority, Section, Essential: they should not pop up in the
binary control files, the distrib-maintainer is responsible 
for them. Source: add only if -p is given, take from sourceinfo

> run debian.rules build, as root debian.rules binary, 

ok. but binary should always depend on build. (even in dpkg... ;-))

> use the new dchanges-a-like with the 
> `arch-dependent files only' option 

should be in ~/.dchanges-a-like setable, also the 
uploader-adr (currently the maintainer field in the .changes,
which is a misnomer as it's only used by dinstall to send the
upload acks to!)

> `read changes information from here' option 

remove that option, it should always use debian.ChangeLog

> To release a new version you make sure that the debian.Changelog 
> has a new entry for your modifications, giving the distribution 
> and version number 

ok. call "dpkg-add-changelog-entry" which asks interactively
(with reasonable defaults) for the distribution, the upstream 
version, the debian release (default 1 if new upstream version)
and a changes entry. 

Sumary:
dpkg-source --rebuild-binary:
  ./debian.rules clean;
  ./debian.rules build; 
  ./debian.rules binary; # as root, runs dpkg-mk-control
  dchanges-a-like --arch-dependend

dpkg-source --rebuild-with-source:
  ./debian.rules clean;
  ./debian.rules build; 
  ./debian.rules binary; # as root, runs dpkg-mk-control
  ./dpkg-source --build  # creates .dsc
  dchanges-a-like        # all .deb .tar.gz .diff.gz .dsc files
                
dpkg-source --release-new-version:
  dpkg-add-changelog-entry; 
  dpkg-source --rebuild-with-source

> If the
> too, so you have to update that as well. 

this should be generally avoided. if i want to change X i must
only change it at a single position. we _can_ ensure this.

> Neither the dchanges-a-like nor dpkg-source PGP-sign the files they

dpkg-source should be configurable in that respect (in ~/.dpkg-source :-)

> Questions:
see above.

my question:
* are there source packages which build binary packages with different
  version numbers? 
  generally this should be avoided. in case this is not possible 
  somewhere: 
  dpkg-mk-control should look in the resp. control file
    source if a version number already exists. if so: leave it in.
    (evtl: warning)
  dpkg-add-changelog-entry:
    check for version numbers in the debian.control* files. if they
    exist: prompt the user if he wants to change them.

* we could just as well skip the .dsc file. why not? ;-))

jjm

-- 
Juergen Menden                   | Disclaimer: The opinions expressed by me, 
tel:    +49 (89) 289 - 22387     +-----------+ are (usually) not the opinions 
e-mail: [email-masked]     | of anyone else on this planet.

Hi! I'm a .signature virus!  Add me to your .signature and join in the fun!

---

From: Miquel van Smoorenburg <[email-masked]>
Date: Fri, 5 Jul 1996 12:39:25 +0200 (MET DST)

>  * Comments ?

How about replacing the "." with a "/". I have done this in my packages
(except for the debian.rules file) and it really helps to keep down the
extra clutter.

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: Dale Scheetz <[email-masked]>
Date: Fri, 5 Jul 1996 12:39:37 -0400 (EDT)

> file <pkg>_<orgver>-<rev>.dsc (optionally PGP-signed).

Is there some, over-riding, reason what the control information and the
diff patch can't be combined into one .dsc file? As both the control file
and the diff file must change for a release that the original source does
not change for, it seems that management of upgrades is easier if only one
file is involved. I don't see this as a compelling reason to have the two
combined, but I see no, more compelling, reason to have them seperate.
Something I've missed?

> now but leave the option open of doing it later.
Shouldn't be any harder than binary packages have been ;-)

   <deleted stuff can be found in previous postings>

>  * What about all this stuff to do with Versions ?

Well it would be really nice if the package builder used the information
from the debian.Changelog to construct the proper package name and version
fields and edit them into the control file in much the same way that
debian.rules edits the binary package control file to properly reflect the
version information.

There are many parallels between binary packaging and source packaging, I
think we should keep as many of these parallels as possible, if for no
other reason than symetry.

Later,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: Steve Greenland <[email-masked]>
Date: Fri, 5 Jul 1996 13:50:48 -0500 (CDT)

> original source, named <pkg>_<orgver>-<rev>.orig.tar.gz and unpacking
                                       ^^^^^^
> file <pkg>_<orgver>-<rev>.dsc (optionally PGP-signed).

Why does the original source have a debian revision field? 

Steve Greenland

-- 
The Mole - I think, therefore I scream 

			DAVE BARRY'S "1986 in Review" -- Mar. 6th:

			    In the Middle East, Iraq uses up all its young
			    men and has to borrow some from Iran so they can
			    keep having a war.
[Dave Barry]

---

From: Lars Wirzenius <[email-masked]>
Date: Sat, 06 Jul 1996 01:15:23 +0300

[ NB: I read the list.  Don't CC replies to me.  I pay for my PPP.  Thanks ]

> file <pkg>_<orgver>-<rev>.dsc (optionally PGP-signed).

The diff and the .dsc could be combined, since patch can skip stuff that
is not part of the diff.  Having two files instead of three is easier,
and in this case it requires no extra packaging (you can just cat the
.dsc and the .diff).

> it will be hard to maintain accurate dependencies for source packages,

Do it later.  It's not that important now.  But allow people to do it
now, if they want to (though no-one should expect it to be complete).

> single binary package named the same as the source.

Yes.

> is may cause with respect to updating and repacking packages.

Is the version of a source package going to be different from the binary
it produces?  If not, get both from the same place.

> We'll need a couple of new required files in the debianised source:

I'm getting the feeling we are having a few too many debian.* files.  It
gets confusing.  Could .sourceinfo and .control be combined, at least?
They do contain similar information.

>  * debian.Changelog format ?

Use the current Emacs format.  It's got the automation support already,
and people know it (even if we don't love it).  Unless there are important
technical reasons to change it?  (Ease of parsing is not important.)

>  * What about all this stuff to do with Versions ?

I'd like to see that it is kept in exactly one location.  Anything else
invites errors.

---

From: Chris Fearnley <[email-masked]>
Date: Mon, 8 Jul 1996 20:21:56 -0400 (EDT)

'Ian Jackson wrote:'
>file <pkg>_<orgver>-<rev>.dsc (optionally PGP-signed).

I like it --- it satisfies the design specs I've identified as
important.

>  <md5-checksum>  <pkg>_<orgver>.orig.tar.gz

Maybe the upstream source URL could go here too?  Most people include
it in the Copyright file, but not always.

-- 
Christopher J. Fearnley            |    Linux/Internet Consulting
[email-masked], [email-masked]       |    UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf         |    (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf    |    Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller |    Explorer in Universe

---

From: [email-masked] (Erick Branderhorst)
Date: Tue, 9 Jul 1996 08:20:15 +0100

> original source, named <pkg>_<orgver>-<rev>.orig.tar.gz and unpacking

I recommend keeping <pkg>_<orgver>.tar.gz and no revision info.  I don't see
a real need for the underscore.  This file doesn't need to have a filename
that can be parsed, and for the simple mget during ftp it isn't needed
either because the "_" can simply be replaced by "*".

> file <pkg>_<orgver>-<rev>.dsc (optionally PGP-signed).

No diff file.  The diff should be combined with the .dsc file.  The .dsc
file can be named <pkg>_<orgver>-<rev>.dsc.  This .dsc file can be an `ar'
archive containing files like: control, md5sum, diff, pgp, changes,
additional patches &c.
 
>  Source: <source-package-name>

Missing support for multiple source packages.  This is required for
combining small packages from different sources into one binary.

>  Architecture: <"any"|"all"|architecture>

Architecture is binary-package specific and can't be defined for the whole
package.  We probably only need to define the architecture for those
packages that can be used on all architectures.

>  Generates: <binary-package> [, <binary-package> ...]

I recommend debian.control like we have right now, but with all control info
in one file.  A small script can extract the proper information from this
file for a particular package and remove fields which aren't required
anymore or obsolete or whatever.  The Architecture field for example can be
set here if it is omitted.  The Generates field wouldn't be required in this
approach.

>   <md5-checksum>  <pkg>_<orgver>.orig.tar.gz

md5sums should go in a seperate file in the archive named md5sum, because
when this is a seperate file/member in an ar archive it can be changed far
much easier then the md5 stuff being part of some control fields sequence.
ar p <package>_<ver>-<rev>.dsc md5sum 
will show all md5 stuff, easy Not?

> is may cause with respect to updating and repacking packages.

Perhaps an extra target should be added to debian.rules.  Creating a pseudo
control field or something would be enough to extract the version
information from there.  Or simply taking the approach that ./debian.rules
version shows the <ver>-<rev> information, and that that is the only way it
should be found.

>   script would read this when it built a source package.

If this replaces all debian.controls then I agree otherwise we might need to
rethink this one.

>   dchanges-a-like for getting changes info for the .changes file.

Yep.
 
>   files and the debian.Changelog.

All fine, but do we really need a template for this or a little smarter
dchanges script.

> debian.sourceinfo file contains all the info you need.

Ok.

> produce a script to do all of these things.

That script would be very handy.
 
>    me what format to expect and users how to represent the required

Don't think ChangeLog is very awful, but it isn't machine-readable. The
suggestion you made a while ago with package and version info specified
seems reasonable to me.

>  * What about all this stuff to do with Versions ?

make -f debian.rules version

>  * Comments ?

multi original sources aren't implemented
no optional patches can be attached

Erick

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 22:39 BST

> (except for the debian.rules file) and it really helps to keep down the

If we're going to change the standard anyway this might be a
reasonable change.  I agree that all the debian.* files are getting a
bit much.

Does anyone object ?

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 9 Jul 96 22:42 BST

Dale Scheetz writes ("Re: Source packaging"):
...
> combined, but I see no, more compelling, reason to have them seperate.

Well, firstly, the two files are conceptually different.  Secondly, we
have to provide something that can be used on a non-Debian system, so
the best encapsulation of the patch we can do is to indent it (we need
to be able to PGP-sign the .dsc file).

I think the first reason is more important.  The two files aren't the
same thing at all, and if we're settling on a multi-file format it
doesn't make sense to shoehorn two files into one.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Wed, 10 Jul 96 00:52 BST

> Why does the original source have a debian revision field? 

It doesn't - that was just an aberration on my part.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Wed, 10 Jul 96 00:55 BST

Lars Wirzenius writes ("Re: Source packaging "):
...
> it produces?  If not, get both from the same place.

It can be, but it usually isn't.  Nice, eh ?

> They do contain similar information.

I think I need to sit down and figure out how much of this information
comes from where and so what can be shared.

> technical reasons to change it?  (Ease of parsing is not important.)

It doesn't have some of the essential information (like `a new version
was released now' and `this version is to go in unstable and
buzz-updates').

That can be added, perhaps, but I think the Emacs format is ugly.

If some Emacs proponent tells me what format their souped-up Emacs
variant uses I can support both their format and mine.

> I'd like to see that it is kept in exactly one location.  Anything else

Quite.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Wed, 10 Jul 96 01:10 BST

Juergen Menden writes ("Re: Source packaging"):
...
> without further notice for different architectures. 

Looking at the package list it seems to me that at least some of the X
packages and some hardware-tweaking things (apmd, for example) may not
be appropriate on all architectures.  Perhaps the win32* don't work as
cross-compilers from a different architecture, for example (I don't
know if this is true, it's just an example).  svgalib and its programs
only make sense on things which can have SVGA hardware.  xosview
probably doesn't work right, because it thinks it knows how many IRQs
there are.  &c &c.

> usable. this is the aim of the control file in the binary

This distiction is needed so that you know whether to bother
rebuilding a source package for a new architecture.  If it says `any'
you do, but if it says `any' then all the binary packages are
arch-independent and so don't need to be rebuilt.

> but the binaries are not for all architectures, which is only

The Architecture field in the source would say `any' if any of the
binary packages involved was arch-dependent.

...
> the sourceinfo and the debian.Changelog. these files should

No, for example the section and priority information doesn't
necessarily want to be in the control file (though it may be), and
there may be other files generated by the package which need to be
uploaded (for example the nondebbin.tar.gz files and guidelines.texi
from the dpkg package).

...
>   dpkg-mk-control [options] [control file name]

That seems like it may be necessary.  I need to do some thinking about
dataflow.

...
> for them. Source: add only if -p is given, take from sourceinfo

You have misunderstood the nature of the Essential field, and also
somewhat of Priority and Section.

...
> which is a misnomer as it's only used by dinstall to send the

No, the arch-dependent files only option should be a command-line
option and not an rc file option, because the same person will want to
do both.

> remove that option, it should always use debian.ChangeLog

No, because if a maintainer is doing a binary upload release they want
to just say
 `binary only release to bring m68k up to date'
or whatever, not to repeat whatever the last i386 (or whatever the
main maintainer's preferred arch is) changes were.

...

Yes.

Ian.

---

From: [email-masked] (Heiko Schlittermann)
Date: Wed, 10 Jul 1996 08:00:24 +0200 (MET DST)

Hello,

when I read about source packaging a perhaps minor thought comes into my 
mind:

Some debian.rules files have (for `diff' and `orig' targets
constructs like `expr $(deb) - 1` to calculate previous or
following debian versions.  

For locally modified sources/packages I appended a `local' to 
the debian version (e.g. uucp-1.06-2.deb --> uucp-1.06-2local.deb).
[ This makes upgradings possible.  If I'd disable automatic upgrades
I'd call it e.g. uucp-1.06-local2.deb (not tested, but I believe it
works).]

But: This breakes the above calculations. 

Shouldn't there be a support for local versions (including version
numbers and such stuff?)  Maybe dpkg could provide a common
set of version calculations for debian and local versions?

Heiko
--
email : [email-masked] [email-masked] [email-masked]
pgp   : A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 
finger: [email-masked]         [email-masked]

---

From: Juergen Menden <[email-masked]>
Date: Thu, 11 Jul 1996 09:32:43 +0200 (MET DST)

On Wed, 10 Jul 1996, Ian Jackson wrote:
> > i'm not sure if we should include this field, 
> 
> Looking at the package list it seems to me that at least some [...]
> packages [...] may not be appropriate on all architectures. 

yes. there are definitely a few of them. but not very much.

ok. it can really help (eg for finding not already ported 
packages, see below).

> > skipped.
> rebuilding a source package for a new architecture. 

better way is by looking in the Binary: field and trying to
find the coresponding binary package in binary-<non-intel>.

this way i also notice which packages need to be rebuild because
of new source versions, and as a side effect i get notices which
binary packages are missing.

> If it says `any'

:-) your statement is the best argument against using all/any.
:-) which one should have been all?

please skip it. it's confusing for everyone.

> uploaded (for example the nondebbin.tar.gz files and guidelines.texi

can be hardcoded by an option to the call of dchanges-a-like
from the debian.rules file. i think this is what the makefile
is about. 

generally there is not much to gain if the options for various
programs are placed in files, if you have a makefile where the
program is called from. place the options there and save a file.

note that the debian.rules file already has to be carefully 
maintained, so there is no drawback from placing this info there.

> I need to do some thinking about dataflow.

right. this is what my post was all about. :-)

> option and not an rc file option, 

ok. but an rc file option for the uploader/maintainer field would
be _really_ nice. :-)

>  `binary only release to bring m68k up to date'

this information helps noone. rather i would like it very much
to see which changes in the source (!!!) were done since the last
source release. note that bug-fixes are a helpful information even
on our m68k arch. :-)

> main maintainer's preferred arch is) changes were.

no. the changes field reflect the changes in the source!
(nevertheless this has some drawbacks on some binaries :-)

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 01:17 BST

Chris Fearnley writes ("Re: Source packaging"):
...
> it in the Copyright file, but not always.

We could make it a policy requirement that the original location of
the original source be described.

I'm seriously unconvinced that a URL would be that useful - it
wouldn't last from one version to another, probably, and would in any
case often yield a file that needed to be repacked and unpacked.

It might be worth suggesting that debian/rules contain a `fetch new
original source' target, which would FTP it from some appropriate
place and do any rearrangement that would be necessary.  Is
`origsource' a good name for this ?

It would have to provide the upstream version number in some standard
way - how about a `make' variable (ie, name=value option to
debian/rules) which gives the name of a file to drop the version
number into ?  Or perhaps it should always put it in
`<sourcepackage>_version' in the current directory ?  (You wouldn't
invoke debian/rules from its own directory in any case.)

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 02:42 BST

...
> find the coresponding binary package in binary-<non-intel>.

That doesn't work.  It only tells you whether the package has been
built yet, not whether it needs to be built.

> binary packages are missing.

I don't follow you.

> please skip it. it's confusing for everyone.

If you have failed to understand what the field and its values are for
you are in no position to say that it is unnecessary.

Feel free to suggest alternative names.

The semantics I intend are:

 all:  The source package generates only arch-independent
       binaries.  Ie, the Architecture field of all the binaries
       is `all'.

 any:  The source package generates at least some arch-dependent
       binary packages, but it should compile and build properly
       for any architecture.  It may only provide a subset of
       the packages on some architectures.

 a list of architecture names (or a single name):
       The source package generates at least some arch-dependent
       binary packges, and will only compile and build properly
       on the architectures listed.  It may only provide a subset
       of the packages on some architectures.

...
> ok. but an rc file option for the uploader/maintainer field would

See my new proposal.  Here the builder calls the program which
generates the .changes file directly, so that they can use a
command-line flag.

This avoids rc files altogether :-).

...
> source release. note that bug-fixes are a helpful information even

Well, then we'll provide a way for the .changes file maker to do this,
but of course you'll somehow have to tell it the version most recently
released for the arch in question so that it can figure out how much
of the debian/changelog to include.

Ian.

---

From: [email-masked]
Date: Tue, 16 Jul 1996 12:09:19 +0200 (MET DST)

> case often yield a file that needed to be repacked and unpacked.

I propose a splitted URL only providing the site and the directory and the
original source file like this:

URL: ftp://ftp.gnu.ai.mit.edu/pub/gnu/ textutils-1.18.tar.gz

This is very informative for humans, easily machine convertible to a
complete url.

> `origsource' a good name for this ?

`getorig' or `getorigsrc' is better or are these in use ?.

Erick Branderhorst  http://www.iaehv.nl/users/branderh/

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 01:50 BST

Erick Branderhorst writes ("Re: Source packaging"):
...
> archive containing files like: control, md5sum, diff, pgp, changes,

I've described already why I think the .dsc and diff need to be
separate.

Having the .dsc be an `ar' is a very bad idea - it makes it
un-editable.

> combining small packages from different sources into one binary.

You call the whole thing one Debian source package which is simply
made by bundling all the upstream source packages into a single
tarfile; we don't need any programmatic support for this (and in fact
it's not much different from, say, downloading a pile of shars from a
sources newsgroup mirror and putting them together).

> packages that can be used on all architectures.

We need to define whether (a) a package needs to be rebuilt for
different architectures at all and (b) if so whether it makes sense to
try to build it for *this* architecture.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 16 Jul 96 15:25 BST

[email-masked] writes ("Re: Source packaging"):
> [Ian Jackson:]

But the complete URL isn't machine-useable when the upstream version
has changed, and a human can just as easily read a README.

> `getorig' or `getorigsrc' is better or are these in use ?.

So, I think that this is a better idea.

Comments on the name of the target are welcome.

Ian.

---

From: Christian Hudon <[email-masked]>
Date: Tue, 16 Jul 1996 13:25:19 -0700 (PDT)

> > case often yield a file that needed to be repacked and unpacked.

Agreed a URL wouldn't be very useful for automated building scripts and
the like. But it *would* be useful for humans. Many people already put a
URL at the top of the copyright file. Maybe it'd be good to standardize
that practice and move the URL where it's more easily accessible to
humans. Maybe 'dpkg -s' could show that URL somewhere.  <shrug>  We could
call it 'Pristine source URL' or 'Originam source URL' or whatever.

> This is very informative for humans, easily machine convertible to a

Maybe. But it's just as easy to extract the host and directory from a
normal URL. So if we're putting URLs somewhere, I think they should be
normal URLs, which everyone is used to seeing. The first thing I saw in
your message was the URL, and the first thing I thought was "Aha! Syntax
error."

> `getorig' or `getorigsrc' is better or are these in use ?.

a) I think the word 'source' should be in there in one form or another,
since it's the *sources* we're getting.

b) How about using dashes or some other form of separator in there?
'get-orig-source' or 'get-origsource' or 'get-origsrc' look more readable
to me.

   Christian

---

From: [email-masked]
Date: Wed, 17 Jul 1996 09:45:43 +0200 (MET DST)

> has changed, and a human can just as easily read a README.

dpkg-source --get-orig-source --use-lynx whatever-package.dsc

will start, fiddle around with the source package, the action is
get-orig-source, call lynx with the first element of the proposed URL
field, show the contents of the gnu dir and lets me select what I want.

This is a far quicker approach than unpacking sources, going through 
debian/README for that URL being there or not, calling lynx or ncftp
and making a type with the site (ok ftp.gnu.ai.mit.edu is a bad example
in this case), rereading debian/README, fixing the typo and then getting
to the original source.

Get the point.  An URL like this (or in the official way) makes sense
if used like this.

Above this, it can be an element of the information which goes in
/usr/doc/copyright/<package>.  IMHO this file should consist of a few
standard fields nice formed together into a sentence, about who did what
with what and gpl'ed it for debian.  Followed by the latest debian/Changelog
changes, followed by the contents of debian/README.

> So, I think that this is a better idea.

`get-orig-source' has been suggested and I think that that one is even
better.

---

From: Dan Stromberg <[email-masked]>
Date: Wed, 17 Jul 1996 15:17:56 -0700

There would be a use for a utility that could:

1) Take a hostname and fuzzily specified package name.  An app-specific
   override might be needed for apps that "don't follow the usual
   naming rules"
2) Use that input to grab "the most recent version" of that package
   (.tar.gz or similar), and any related patches.

Tools for building up an executable from the .tar.gz (plus patches)
already exist.  We've been seeing good results with one locally.

With such a program at hand, of course, rebuilding an entire OS could
become a series of:

1) Fetch the program
2) build it
3) install it
4) blow it away, or leave it around to be expired later

An interaction between the "fetcher" and the "builder" could also be
beneficial, like:

1) Fetch the most recent
2) Attempt a build
3) Find that the build glitched, via an app-specific test for presence
   of executables or similar
4) Iterate over fetching the previous versions, back thru the last   
   version known to work ok
5) finally build something that at least produces executables
6) install it
7) blow it away, or...

---

From: Juergen Menden <[email-masked]>
Date: Thu, 18 Jul 1996 11:48:24 +0200 (MET DST)

please don't try to make the .dsc file and the corresponding 
tools to inteligent. for a reliable package maintaining it
is _essential_ that some human mind carefully controls
upgrading.

> 5) finally build something that at least produces executables

a really bad idea.

at least for now we should leave this subject an open one, but
include a 
   Version:
line in the .dsc file. please let us stick to the core tools we
need for now. we still can later expand our toolset if needed.

another thing: the name of the tools. i find it anoying if i
always have to write
   dpkg-... (eg dpkg-source)
for all debian specific tools. i think
   d-...    (d-source)
is enough, or (like in dchanges or dinstall) simply
   d...     (dsource)
(this last line also conforms with dpkg)

jjm

---

From: Dan Stromberg <[email-masked]>
Date: Fri, 19 Jul 1996 13:02:45 -0700

> > 5) finally build something that at least produces executables

A really bad idea, or one who's time hasn't quite come?

I strongly suspect that given an adequate initial-investment of time in
solid regression tests, something like this would increase free
software's pace considerably.

Upstream maintainers would then include software, doc, regression tests,
and especially, clear indications of "how stable" a package is
considered, in a manner that a script could inspect and use.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 19 Jul 96 21:17 BST

Christian Hudon writes ("Re: Source packaging"):
...
> call it 'Pristine source URL' or 'Originam source URL' or whatever.

We already require that the copyright file say where the package came
from.  Given that there may be no such thing as a URL and that we
can't make it machine-parseable anyway what's the gain in mandating a
URL in the source control information, compared to mandating
information about the original source in the debian/README ?

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Fri, 19 Jul 96 21:29 BST

> field, show the contents of the gnu dir and lets me select what I want.

This is nonsense, because the URL field will not have useable
information.  The original source target in the debian/rules can
handle this and we don't need to add anything to dpkg-source to
support it.

Ian.

---

From: [email-masked] (Erick Branderhorst)
Date: Mon, 22 Jul 1996 11:32:33 +0100

> handle this and we don't need to add anything to dpkg-source to

This isn't nonsense.  The URL field has the directory where the original
source comes from.  If one wants to update the package (mainstream update)
because for some reason the debian package isn't updated by the maintainer
or the maintainer like this procedure more than another, this approach is
perhaps not the best but very reasonable IMHO and surely not nonsense.  

The original source target can only produce the source like it comes in the
current debianized sources.

Erick.