[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: