Re: Bug#457353: gdome2-xslt: should not be a Debian-native package
Gabor Gombas <gombasg@sztaki.hu> writes:
> Huh? I, as a user, routinely use upstream-provided debian/ directory to
> create packages for some software (most frequently mplayer). So those
> are not assumptions but facts.
> And as a user, I can say that if e.g. the debian mplayer maintainer
> considers the upstream-provided debian/ directory inconvenient, I
> couldn't care less. If the upstream-provided packaging is not perfect or
> does not fully follow Debian guidelines - I do not care, as long as it
> _works_.
I don't think this is horribly relevant to what we're discussing, namely
how to go about packaging software for inclusion in Debian. Generating
upstream-provided packages that don't meet Debian Policy and therefore
won't be included in Debian but which are useful for some users is
certainly of interest to some, but it seems rather off-topic for
debian-devel. We're focused on including software in Debian rather than
creating problems like one sees in the Red Hat world where there are
random RPMs scattered hither and yon all over the net that may or may not
work together.
>> I remove the upstream debian/ directory because the program that
>> create the diff.gz (dpkg-deb ?) does not record *removal* of files [1].
>> It only record changes. And I need to remove some files...
>> A workaround can be to add 'rm debian/....' in the 'clean' and 'configure'
>> target of debian/rules but I think it is a lot clearer with a new
>> upstream tarball without debian/ directory.
> Then why not just do the unpacking of the upstream tarball from
> debian/rules? That way you can use the unaltered upstream tarball yet
> the .diff.gz will contain just your version of debian/.
Some people do like packaging software this way, but it's controversial,
and some of the groups who routinely have to work with other people's
packages (release team members, security team members) have expressed
annoyance at having to deal with it. Depending on the maintainer, it may
be a reasonable solution, but I don't think encouraging more use of
dbs-like systems is going to achieve a lot of consensus.
> There is also the method e.g. nut upstream uses that can be viewed as a
> compromise: they put the upstream-provided packaging info into a
> subdirectory (packaging/debian), so it does not conflict with the
> distro-provided packaging.
This, of course, is ideal from a Debian packaging perspective. It would
be nice if more upstreams who feel like they *really* want to provide
packaging files for Debian would use a strategy like this.
My experience, though, with maintainer-provided Debian packaging files
except for the special case where the Debian and upstream maintainer are
the same person is very poor. The Debian packaging often hasn't been
updated, doesn't reflect the current version of the package, may be
written for some ancient release of Debian and sometimes won't work with
unstable, and often has dependencies that reflect whatever the last person
to touch it had sitting around on their system. They maintain their
Debian packaging about as well as they maintain their RPM spec files, but
Debian puts more effort into integration and transitions and sloppy
packaging is far more apparent than it is in the messy RPM universe.
In most cases, the Debian packaging files end up just confusing users and
the upstream maintainer would be better off deleting them and letting the
Debian packager do their job.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: