Subject: dchanges-3.3 and package names

From: Dale Scheetz <[email-masked]>
Date: Mon, 1 Jul 1996 10:58:28 -0400 (EDT)

In upgrading debian.rules in various packages I have incorporated the use
of dpkg-name to name the package source file "correctly". The problem that
results, comes from the fact that dchanges has the comparison string for a
package name hard coded into the script. I was able to hack the new file
name structure into this code, but it would be much nicer if the script
could use dpkg-name to do the name verification. This would make dchanges
"always" compatible with the current naming convention (it seems like it
may yet change again!). It's not clear to me how you would get dpkg-name
to do this for you, but maybe Ian could help make it possible.

Thanks,

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: [email-masked]
Date: Tue, 2 Jul 1996 09:03:16 +0200 (MET DST)

> to do this for you, but maybe Ian could help make it possible.

One might only use dpkg-name on .deb files. It reads the info by using
dpkg-deb.  This information can't be extracted from .tar.gz and/or .diff.gz 
files.  That is the reason why I'm opposed changing the .tar.gz and .diff.gz
names.  At least for this moment.  If it can't be done automatically don't
do it (IMHO).

dchanges thinks otherwise (unfortunately).

Erick
                                                                D.E. Knuth
Erick Branderhorst  http://www.iaehv.nl/users/branderh/

---

From: Dale Scheetz <[email-masked]>
Date: Tue, 2 Jul 1996 07:48:22 -0400 (EDT)

> names.  At least for this moment.  If it can't be done automatically don't

It is the .deb file that is causing the problem with dchanges. The naming
of the .deb file is now controled by dpkg-name, and currently dchanges is
out of step with dpkg-name.
Probably what is needed is an option for dpkg-name, like --print-pkgname,
so that dchanges could verify that the package is named correctly.

I don't even want to bring source package naming into this discussion.

> dchanges thinks otherwise (unfortunately).

Exactly!

Later,

Dwarf

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

---

From: Andy Guy <[email-masked]>
Date: Mon, 08 Jul 1996 12:53:02 -0600

>> dchanges thinks otherwise (unfortunately).

Version 3.4 (uploaded a couple of weeks ago) uses the new scheme for
.deb files and source files (producing warnings for the old style).
Eric dosn't like using it for source files, Guy does and so do I.

I can easily upload a new version that uses the old scheme for source
if that is what is required - but looking at debian-changes some
people have already made the change.

I am really looking for Bruce to make a pronoucement.

Andy.

---

From: Dale Scheetz <[email-masked]>
Date: Tue, 9 Jul 1996 08:08:16 -0400 (EDT)

> I am really looking for Bruce to make a pronoucement.
It would be much better, if dchanges could automaticaly track naming
convention changes, in much the same way that debian.rules has recently
been changed to incorporate the automatic name production provided by
dpkg-name. If dchanges could use a feature in dpkg to verify proper
naming, then whenever the naming convention changed, and dpkg reflected
that change, dchanges could automaticaly reflect the same changes, without
re-coding.

Thanks,

Dwarf

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

---

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

> to do this for you, but maybe Ian could help make it possible.

In actual fact the names given to the files are probably not that
critical at the moment.  They get renamed when they're put in the
tree.

I think we should defer changing all the packages to use the new
format filenames until we have decided on the new source format, so we
can do everything at once.

Ian.

---

From: Guy Maor <[email-masked]>
Date: Wed, 10 Jul 1996 10:29:40 -0500 (CDT)

> Eric dosn't like using it for source files, Guy does and so do I.

dinstall renames ALL files when it installs them, so it doesn't really
matter what naming convention you use in the .changes file.

Guy

---

From: Dale Scheetz <[email-masked]>
Date: Wed, 10 Jul 1996 13:54:39 -0400 (EDT)

> matter what naming convention you use in the .changes file.
Well then, maybe dchanges shouldn't make any demands on a package name.
Sounds like we have management on both ends of the problem. What's the
point, aside from yet another way to wedge things?

Thanks,

Dwarf

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

---

From: Dale Scheetz <[email-masked]>
Date: Thu, 11 Jul 1996 12:05:11 -0400 (EDT)

> critical at the moment.  They get renamed when they're put in the

So, there is no need for dchanges to do any name validation, other than
possibly verifying that the file exists. Whatever the file is named it
will get fixed at archival time.

> can do everything at once.
With the use of dpkg-name currently in place, the only thing a maintainer
needs to do to incorporate any new naming convention is to upgrade to the
version of dpkg that supports the new convention. This seems to me to be a
pretty seamless/painless method of creating compliance.

Thanks,

Dwarf

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

---

From: Guy Maor <[email-masked]>
Date: Wed, 10 Jul 1996 15:05:06 -0500 (CDT)

> point, aside from yet another way to wedge things?

dchanges and the changes file format are two different things.  There's
lots of information in the changes file that dchanges figures out for
you.  It restricts you so that it can more reliably produce a
well-formed changes file.

I really don't think that this is such a big deal.  dinstall requires
binary files to match /\.deb$/ and source files to match
/^$name[-_]$vers\.(tar|diff)\.gz$/ where $name and $vers are as given
in the .changes file.  Any changes file that you produce whose
filenames match those regular expressions is ok.

Guy

---

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

Dale Scheetz writes ("Re: dchanges-3.3 and package names"):
...
> pretty seamless/painless method of creating compliance.

This assumes, I think, that most future changes will be just to the
package filename format.

I don't think this is true - we don't have a format-of-the-week now.

The next change will be the source format reorganisation, I think.

Ian.

---

From: Dale Scheetz <[email-masked]>
Date: Tue, 16 Jul 1996 09:08:44 -0400 (EDT)

> This assumes, I think, that most future changes will be just to the

Well, that is the topic of the discussion ;-) but seriously, the more of
the variable part of this management problem that are "contained" within
dpkg and it's children, the easier these changes become to implement.

> I don't think this is true - we don't have a format-of-the-week now.
Well, it sure has felt that way lately...we have gone through at least
three cycles of changes in package naming in at least as many months.

> The next change will be the source format reorganisation, I think.
Hopefully, controled by dpkg in the same way that dpkg-name manages the
format of binary package names.

My fundamental problem with the current state of dchanges is that it is a
seperate package from dpkg. There is such a tight relationship between
dchanges and dpkg, that whenever dpkg changes, dchanges must be changed to
conform. This would be easiest handled if both programs were in the same
package (more work for Ian...sorry). 
On the other hand, if dchanges weren't so pedantic about checking filename
format, and comparing internal and external package names, then the only
time upgrades are necessary is when the changes format is modified, or
features are added to the program.
My feeling is that this is supposed to be a tool that helps the maintainer
do his/her job. Yet every time I have used it in a new situation, I have
had to hack the code to make it work.
I have heard the argument that these verification efforts are in aid of
producing a "well formed" changes file, yet every time I have removed or
modified the validation schemes the well formed nature of the changes file
have not been impacted. I see no reason for dchanges to go any farther
than checking to make sure that the files you specify in the command line,
are, in fact, files on the disk. Since the archive maintainance tools do
all the necessary validation before installing a package, having these
checks in dchanges is redundant and just gets in the way.

Later,

Dwarf

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

---

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

> seperate package from dpkg.  [...]

Yes.  When we have the new source format decided on all the
implementation, including the thing that produces the changes file,
will be in dpkg.

Ian.

---

From: "James A. Robinson" <[email-masked]>
Date: Tue, 16 Jul 1996 17:38:36 -0400

> checks in dchanges is redundant and just gets in the way.

I might be misunderstanding you, but do you mean it gets verified
after it gets uploaded?  For those of us with only modem connections
to the net, that is a big deal.  I like having dchanges, when it is up
to date, warn me of a problem in my package before it gets uploaded.
I waste much less time that way.

Jim

---

From: Dale Scheetz <[email-masked]>
Date: Tue, 16 Jul 1996 19:42:08 -0400 (EDT)

> I waste much less time that way.
Well, if you use dpkg-name in the creation of the package, then you only
need to be up-to-date with dpkg and you will create a properly formed
package name. My complaint is that dchanges does not track these changes
until after they happen and require upgrading to a proper dchanges as well
as dpkg.

Later,

Dwarf

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