Re: Keeping information on the build system
On Sat, 13 Oct 2001, Yann Dirson wrote:
> [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 ?
The question remains whether that is a valid goal. It just adds clutter
that doesn't serve any purpose. What you want (being able to build without
having all packages in build-essential installed) is currently possible.
And I'm quite sure that you don't want to go through all packages having
"Essential: yes" and decide whether you really need them or not.
Especially since some of them need eachother -- which is normal, since
they're essential.
> > 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 ?
No, you want to add this header so that people can know which packages can
be removed if they want to. It doesn't make sense, IMHO.
> 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.
They're accurate enough. There's no reason to create this clutter.
> > Build-essential was created so that people wouldn't start doing
> > build-depends on obvious packages. Not because you have to build-depend on
> > them.
>
> 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
> anyway.
Are you sure? Build-essential gives flexibility to people. See below.
> 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.
Right.
What happens when a future port has no decent g++ yet, but does have
another compiler that works the same way in most cases? Create some
alternative on that port only, so that packages think they're using g++
while in fact they're not? Override build-dependencies? Looks pretty
uggly to me.
What happens when you want to use some other alternative compiler, but the
package defines whatever happens to be default, even if the source is
ANSI?
The choice of which compiler is used should be left to the people that are
actually compiling the thing. There's more in the world than gcc/g++.
Think stackguard, for example. Your proposal is not really creating
possibilities, while it makes some things difficult.
--
wouter dot verhelst at advalvas dot be
"Human knowledge belongs to the world"
-- From the movie "Antitrust"
Reply to: