Re: Keeping information on the build system
On Sun, Oct 14, 2001 at 02:00:36AM +0200, Wouter Verhelst wrote:
> But even in this case, I see no need for an extra header telling which
> version of a certain tool or something likewise has been used. When a
> program has been compiled, it works; no matter which version of autoconf
> you used, no matter of which compiler you used, a compiled program works.
Except in the case of a compiler bug.
For all this to work, we would also need a way for package maintainers
to tag (eg. in the changelog) revisions that are likely to require a
rebuild of build-depending packages. A short script can then
summarize in the control file something like "Requires-Rebuild-From:
x.y-z", that a robot can use to tell "you've built package foo with a
version of bar older than x.y-z", please consider rebuild it".
> The only important thing is the library. However, used libraries are
> easily detected by their version number in the "Depends:" line.
Not really. 1. the build-dep is on the -dev package, which may or may
not be in sync with the lib, maybe depending on particular cases
2. this "Depends:" info is taken from the shlibs file provided by the
lib package, and I'm not sure there will be a 100% correlation between
the "need to rebuild" and the "need to work" relations they define.
But maybe this info could be taken as a default ? This would be worth
checking.
> remember that build-essential includes "plain" essential. If you
> want to state which packages you *did not* use during a build,
> you'll have to check that.
Not necessarily. I currently distinguish in the listing between
essential, build-essential, and build-deps. Nothing forces us to give
them the same treatment.
Joey's point was to avoid forcing the installation of all
build-essential packages that would not be needed (g++, etc.). This
point does not exist for essential packages.
> It won't be fun when you have to do that manually -- which would be a
> stupid idea anyhow -- but even if you don't do it manually, it's kinda
> hard to explicitely state what has not been used during a build.
Yes, that's why I think it's better to list all essential packages, at
least for reference in case some obscure problem shows up.
> If a package gets added to build-essential or essential, then you'd
> have to add these packages to all "Build-Unused" (or whatever you
> want to call it) of all already compiled packages.
No. This "Build-Unused" I suggest is just a hint to:
1) prevent unnecessary install of unneeded build-essential packages
(Joey's point, for which I think I have another solution - see
somewhere else in this thread)
2) prevent unnecessary listing in the buildinfo file. But this would
have a major drawback even in this case: when a package previously
listed in Build-Unused becomes needed, the maintainer may just forget
to remove it from the list, and then we loose (part of) the
usefuleness of the buildinfo listing.
So if we aggree on the fact that 1) can be solved without this extra
information, I see no more need for it.
--
Yann Dirson <ydirson@altern.org> | Why make M$-Bill richer & richer ?
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
Pro: <yann.dirson@fr.alcove.com> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Reply to: