On Thu, Dec 27, 2007 at 10:18:38AM -0800, Russ Allbery wrote:
> 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.
Well, this was in response to "having debian/ in upstream release is
harmful" opinions. You're right that the best thing would be to have
everything packaged officially, but in reality sometimes that just does
not work out, for various reasons:
- Having to work with unreleased development snapshots because the
official release does not yet have some critical (for me) feature
- Maintainer not uploading new upstream versions for a long time
- Official package lacking some feature due to legal reasons that may be
important for Debian as an organization but not for me as an
individual
In these cases upstream help for creating a Debian package is really
nice as it saves me time. Of course it can be expected that the
upstream-provided packaging does not play nice together with official
Debian packages but as long as having to install unofficial packages is
the exception rather the norm I'm willing to pay that price.
> > 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.
Maybe it should be described somewhere on www.debian.org why is this the
preferred method. I suspect most upstreams providing their own packaging
simply do not even aware that it may cause problems for distro makers.
> 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 general I agree with you. However in my experience fixing the
upstream-provided packaging to the point when I'm able to build an
installable .deb is just 1-2 minutes, much less than having to create
debian/ from scratch. Yes, it is a hack, it may not be perfect (or it
may even be completely buggy from a packaging POV), but it saves _me_
time and that's what counts.
Maybe the webpage proposed above should also mention that binary
packages built using the upstream-provided packaging scripts should not
be put on the web, so it is less likely that people unaware of the
possible risks download & use them.
(Btw. I'm quite aware of the "RPM hell" problem. We're running
Scientific Linux on our grid nodes, and every gLite upgrade - even just
to update the CA certificates - tends to break the system in new and
exciting ways...)
> 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.
In an ideal world, maybe. But until then they are useful.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
