Re: update excuses.. how to read them
Hi!
On Thu, 25 Jan 2001, Joey Hess wrote:
> Daniel Kobras wrote:
> > It's not as easy as that. Consider the upstream and the Debian maintainer
> > being the same person. But still they want to keep separate upstream and
> > Debian changelogs. Now, debhelpers will scream if you build a native
> > package with separate changelogs, but you can't build a full non-native
> > package either because there is no diff to the upstream sources. The
> > outcome if this usually is one of these strange native packages with
> > Debian revision number. (The revision number not making much sense as
> > you'll have to do a full upload for every minor change anyway because
> > there's no .orig.tar.gz.) I for one have this very problem with noflushd
> > and haven't found a good solution yet.
>
> Well I could always change debhelper. That check is in there as a sanity
> check, I have seen it help developers many times when they were making a
> mistake, but if it is a problem I can take it out.
Sure. Or I might hack around it locally in debian/rules. Adding a cp+gzip
is no big deal really. The thing is--I clearly see why the debhelper check
actually makes tons of sense. In a native package there shall obviously be
no separate Debian changelog. That's the whole point of being native. The
question is rather how to deal with packages that are not native, but
contain an upstream-merged debian/ directory, so there never a diff for
the x.x.x-1 Debian revision (but there may be diffs for later revisions
without an accompanying new upstream version)? Those packages a) do exist,
and b) currently don't fit well in out packaging scheme. Suggestions
welcome.
Regards,
Daniel.
Reply to: