Re: Backports - Best practise (or something similar)
Daniel Baumann <daniel.baumann@panthera-systems.net> wrote:
> Since the website on www.backports.org is quite oudated wrt/ backporting
> rules and I can't modify it myself, I added a few sentences about the
> most important things to http://wiki.debian.org/Backports
Thank you.
But isn't the information a little contradictory?
,----
| 5. Always build against plain sarge (and include other backports only
| if absolutely needed).
`----
,----
| * Do not convert a package to a lower debhelper version for creating
| the backport, debhelper 5 is already on backports.org, just use it.
`----
Furthermore, I'm not sure whether it is actually a good idea to follow
recommendation 5. It's fine if you don't need other backports as
build-dependencies. But as soon as you need at least one, or even a
couple of them, isn't it safer to keep a pbuilder tarball that is kept
up-to-date with respect to backports.org, and build in that? Otherwise,
I would have to manually make sure that the needed backports are
available, and that they are up-to-date if needed.
And I would need a couple of such tarballs if I'm going to backport
multiple packages: tex-common would be built against plain sarge;
tetex-base against sarge plus tex-common and debhelper from
backports.org, and tetex-bin against sarge plus tex-common, debhelper
and tetex-base from backports.org. And if I start to provide backports
for something unrelated, I need yet another tarball.
That way lies not only disc consumption, but IMO madness.
I would rather suggest to adjust build-depends (for example, if a
package in etch has
Build-Depends: libfoo<etch_soname>-dev | libfoo-dev
and libfoo<etch_soname>-dev is available on backports.org, change it to
Build-Depends: libfoo<sarge_soname>-dev | libfoo<etch_soname>-dev | libfoo-dev
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Reply to: