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

Re: Doing RFS on -mentors

On Mon, Apr 10, 2006 at 01:32:16AM -0700, Don Armstrong wrote:
> > > And do whatever needs to be done so a .diff.gz shows up in my browser,
> > > rather than making me download it :)
> > > More seriously, this brings me to a practical reason to use non native
> > > packages (and of course pristine, where possible).  These are not just
> > > theoretical things, but actively make things more difficult for me.
> > That's a good point. Actually, the only thing that still troubles me
> > with these rationales is that they apply equally well to Debian
> > specific packages. IOW, to ease peer review and NMU'ing, _every_
> > package should be non-native, with no exception.
> The reason why they don't apply so well is that the debian native
> packages which are properly debian native do not have revisions that
> only change the packaging information; each version is a new upstream
> revision. [You can think of them (somewhat imprecisely, but whatever)
> as non-native packages with a null diff.gz if that helps...]

Yes, this is quite much the definition of being a native package :)

I understand this, but it was exactly the same situation as with my
software packages -- they didn't have separate packaging and "upstream"
changes.  There have been two times in their history when only packaging
information has been changed: when I added packaging for the first time,
and when I incorporated the fixes proposed on -mentors.  Other packaging
changes have always been accompanied with changes in the software
itself.  Note that technically even Debian specific packages can quite
easily be separated into packaging-related and other stuff.

My point is that there's nothing that connects the requirement "has some
use outside Debian" to the (small but existing) technical benefits of
separate packaging information and packaging-level version numbers.  The
only kind of package I can think of that really has no point in
separating these concepts is a package where all the content _is_
packaging, such as build-essential and some other (half) pseudo
packages.  And in these packages, it would be better to distribute them
with null .tar.gz and everything in .diff.gz, not vice versa :)


personal contact:	panu.kalliokoski@helsinki.fi, +35841 5323835
technical contact:	atehwa@iki.fi, http://www.iki.fi/atehwa/
PGP fingerprint:	0EA5 9D33 6590 FFD4 921C  5A5F BE85 08F1 3169 70EC

Reply to: