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

Re: 1 source, 2 binaries, 2 CFLAGS and cdbs

On 6/25/06, Neil Williams <linux@codehelp.co.uk> wrote:
Eddy Petrişor wrote:
>> ? I didn't say to do that. Patching the Makefiles used by autotools
>> before cdbs runs was my point.
> Err, yes, my bad, indeed, you did not say that.

OK, I see the problem. I've used "autotools" where I really meant
"automake" - i.e. the normal make process that all binary packages need
to be built from the upstream source tarball. ./configure, make, make
install. That was my bad - I'm upstream as well as maintainer for all my

>> autotools are run (once) via the normal cdbs processes as before, but
> Err, didn't you say that you were not advocating running autotools
> from debian/rules? Or am I missing something?

Yes, but it wasn't really what I meant. Sorry.

No problem :-)

> As I said, I doubt any sane upstream would incorporate rules to build
> their software configured differently just to please Debian. I, for
> one, would not welcome our new autotools-fiddling-for-debian changes
> :-) .

It depends, I try to keep in touch with a Fedora maintainer for my own
packages and his experiences help me create an upstream tarball that
suits both Debian and Fedora - in the hope that it will also be easier
to use on other systems. In my upstream work, I'm not aware of any
objections to making the released code easier to build on a wider range
of systems. All these conditional build settings can be made into
./configure options and then it's easy to request cdbs to use or not use
specific options. There's no need for this change to force everyone else
to build 2 binaries, just adding support for those who do need 2. This
example could be made "--enable-libfoo386" with a default to no.

that makes sense

If this is expressed as an architectural thing rather than Debian-only,
upstream may well be willing to at least help out. Asking for
"--enable-libfoo-deb" is not the idea. Upstream will (and should) tend
to see Debian-only problems as "not our fault" but - to me at least -
the original question was an architectural issue that could apply to
other distributions. That can be a key factor in how the request is
phrased to upstream.

Indeed. That is in a different ballpark.

For some reason I imediately thought of thinks like
--enable-supplemental-full-option-build-after-the-custom-build .

"Imagination is more important than knowledge" A.Einstein

Reply to: