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

Re: native packages



On Mon, 12 Apr 2004 15:42:45 -0500, Chris Cheney wrote:

> On Mon, Apr 12, 2004 at 08:32:10PM +0100, Henning Makholm wrote:
> > > but maybe someone else could be so kindly and code it.
> >
> > The first step would be to muster a consensus that it is indeed always
> > wrong to have no .diff.gz for a package with an upstream author
> > outside Debian. I'm not quite sure such a consensus exists today.
>
> A more accurate statement would be it is always wrong to have no
> .diff.gz unless the package is only useful for Debian. Not just with an
> upstream author outside Debian. There are very few packages in Debian
> that should be native.

I think I would have to respectfully disagree with that statement.
What if an upstream author who is a Debian developer includes a fully
working debian/ directory along with, say, an rpm .spec file, in the
main sources so that extracting the sources and running
dpkg-buildpackage is all that is required for this person to build the
package?  Would a .diff.gz be required in that case?  I would argue
that it would not (since there's nothing to diff) even though the
package may be useful outside of Debian.  It would also be possible
for the DD who maintains a package to be in close enough cooperation
with the upstream author to have the upstream author maintain a debian
directory whose control file includes the Debian maintainer as
maintainer.  Assuming my goal of becoming a DD is eventually met, I
will be participating in both of these arrangements.  (In the latter
case, any Debian-specific files would be merged into the upstream
sources, the upstream author would make a release, and I would
immediately create the Debian package.)  Clearly someone who did an
NMU would have to generate a .diff.gz, probably with a -0.1 Debian
version, but any package built by the maintainer would require no
modifications at all -- even for a changelog or control file -- from
the upstream version, even though the package is useful outside of
Debian.  Maybe I'm splitting hairs, but it seems to me that it would
appropriate to treat this as a native package.  It may even be
inappropriate not to.

It seems to me that the criteria should be that if any changes at all,
even including just adding entries to a changelog file or setting the
Maintainer field in a control file, are required from the pristine
extracted upstream source, then a .diff.gz must be there; otherwise, a
.diff.gz must not be there.

On Mon, 12 Apr 2004 13:28:35 -0700, Shaun Jackman wrote:
> I won't say anything useful here, but simply add a "Me too!". I
> would say the following two statements always hold:
>
> 	version contains '-' implies not Debian native (i.e. orig/diff)
> 	not (version contains '-') implies Debian native (i.e. tar.gz)
>
> If either of these fails, I think lintian/linda should definitely
> complain. Can anyone think of a counterexample?

Not exactly a counterexample -- more like an almost could have been
counterexample. :-) The libxml-xerces-perl package (upstream:
Xerces-perl) has a dash in its upstream version number (see
xml.apache.org).  The current upstream version is 2.3.0-4.  The
current Debian package is 2.3.0-4-0.1.  This isn't a counter example
because this is not a native package.  In principal, the upstream
author could make a native package using his upstream version number
which would create a counterexample.  I guess in this type of package,
if the upstream author were a Debian developer and wanted to package
the software as a native package, said developer could change his
version numbering standard.  (This could have been 2.3.0.4, for
example.)  For what it's worth, this upstream version is most likely
the way it is because version 2.3.0-4 of the Xerces-perl package
depends upon version 2.3.0 of the Xerces-C package.  (In general, a
version of Xerces-perl depends upon a specific version of the
lower-level Xerces-C package.)

-- 
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/



Reply to: