Re: Keeping information on the build system
[please CC me on followup]
> > OTOH, we could take the approach of listing in build-essential the
> > tools that are most commonly used so that everyone does not have to
> > list them, and allow maintainers to specify a Build-Unused list of
> > build-essential packages not in use.
> That wouldn't make sense.
> Build-Depends was created so that a package could be built easily. Not so
> that you'd know what software is used to accomplish the build.
Should this fact stop us from adding the missing information to
accomplish that goal ?
> You know, build-essential packages an extension to essential packages. If
> you want build-essential packages to be installed, you need packages with
> "Essential: yes" to be installed too. That includes base-files, which is
> rarely used when doing a build. But would you uninstall it "because you
> don't need it for this build"? I doubt that.
Did I wrote that any package marked Build-Unused had to be removed ?
We have Build-Conflicts for that already. In my mind this
Build-Unused is just meant to allow us to keep the flexibility we
currently have with the contents of the build-essential list, while
adding enough info for buildinfos to be more accurate.
> Build-essential was created so that people wouldn't start doing
> build-depends on obvious packages. Not because you have to build-depend on
Agreed. But if we want to go further (which I think is the case), we
can add the necessary informations - and that's quite a low cost
The only costly approach would be to remove g++ from the
build-essential list. Although I support this approach, it does not
have to be done right now: we could just mark it as "depreciated as a
build-essential package", and start mentioning it explicitely. Then
sometime, hopefully during the 3.1 development cycle, we can remove it
from the list and fix the remaining packages.
Anyway, if/when C++ programs start to use features available in g++3
(correct me if I'm wrong - I believe this includes namespaces and
other modern features whose use is encouraged), those build-deps will
have to be explicited anyway.
Yann Dirson <email@example.com> | Why make M$-Bill richer & richer ?
Debian-related: <firstname.lastname@example.org> | Support Debian GNU/Linux:
Pro: <email@example.com> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>