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

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



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
current packages and it's easy to forget where one stops and the next
starts for other maintainers who are not also upstream. Sorry for the
confusion.

>> OK, so maybe that method requires at least some upstream assistance -
>> but I wasn't actually advocating running autotools in debian/rules. My
>> point is that by tweaking the Makefiles and associated build scripts
>> with patches, there would be no need for changes in debian/rules at all.
> 
> I sincerely doubt any sane upstream would incorporate changes to make
> their source compile in two different configurations of the same
> software just to please Debian.

Maybe, but I (as upstream) have incorporated changes upstream to support
two different architectures of the same source before. I found that
MacOSX/Fink requires frequent autotools tweaks upstream and there are
other tweaks for Solaris, etc., etc. This change - as I read the
original question - is more of an architectural thing than a tweak only
to suit Debian. It could well help other maintainers like Fedora or SuSE
who also have to build for specific architectures.

>> 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.
:-(

I meant ./configure make make install, nothing more. Patch the upstream
source (using cdbs), run the rest of cdbs as normal.

> 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.

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.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: