Re: Advice on how best to handle non-backwards compatibility
On Friday 09 January 2004 03:15 pm, Andrew Pollock wrote:
> On Fri, Jan 09, 2004 at 12:44:09PM -0600, Steve Langasek wrote:
> > On Fri, Jan 09, 2004 at 11:19:18AM +1000, Andrew Pollock wrote:
> > > I'm of the philosophy that a Debian package of upstream software should
> > > reasonably accurately represent what you'd get if you nipped off and
> > > grabbed the source tarball yourself and built it. For that reason, I'm
> > > reluctant to bolt on part of lprngtool 1.1.1 onto lprngtool 1.3.2, but
> > > that is just my personal philosophy towards packaging, to avoid
> > > breakage, it may workout better to do as you've suggested.
> >
> > FWIW, I disagree; providing continuity of functionality across upgrades
> > is one of the most important value-adds we offer over upstream tarballs.
How about a backwards compatibility package, built from the lprngtool 1.1.1
source package, that contains the "runtime" portions, and some sort of
Recommends / Suggests / Replaces magic so that dist-upgrade installs both the
new lprngtool and the old runtime? The Description of the old runtime could
say, "If your /etc/printcap doesn't reference such-and-such script then it is
safe to remove this package."
> Yeah that's fair enough. I don't have a problem with that. I guess it just
> means that a Debian package of upstream software isn't necessarily
> indicative of how the upstream software walks and talks both a) in the wild
> and b) on another Linux distribution (point (b) being one of my pet hates
> of distributions like Red Hat Linux and both points yielding varying
> degrees of the gotcha factor for users migrating to or from Debian)
Depends how responsive the upstream is to packaging-oriented patches. Debian
mechanisms are needed for compiling catalogs of accessible components (elisp,
SAX parsers, XML DTDs, info nodes, etc.) when the upstream mechanism doesn't
take kindly to being separated from the "make install" target. Upstream's
approach to modular release/installation can make things better (perl) or
worse (python).
> Andrew
- Michael
Reply to: