Re: Bug#19849: libc6-dev: Please recommend gcc | egcc
On Tue, 17 Mar 1998, Dale Scheetz wrote:
> On Tue, 17 Mar 1998, Scott K. Ellis wrote:
>
> > On Tue, 17 Mar 1998, Dale Scheetz wrote:
> >
> > > Well, let me put it to you another way...Why is it libc6's responsibility
> > > to work out a problem between gcc and egcc. Libc6-dev depends on gcc and
> > > does not, at this time, depend on egcc.
> >
> > It provides a VERSIONED dependancy on gcc, which egcc can never provide.
>
> The libc6-dev dependency on gcc is correct, and is there for stability
> reasons.
>
> "which egcc can never provide."? In the first place it is only necessary
> that egcc install along side gcc. (If we can provide different,
> concurrent, versions of gcc {libc4 and libc5...libc5 and libc6}, then why
> not egcc along side gcc?) In the second place, any package can declare
> versioned dependency...I don't understand your point...
Yes, but since you depend on a specific version of gcc, egcc can't just
"Provides: gcc" and replace gcc. I understand the reason why the
versioned dependancy, since apparently earlier versions of gcc can't
handle libc6 (although the percise reasoning why they can't is something
beyond my immediate comprehension). That doesn't change the fact that a
package called egcc can never satisfy the dependancies of libc6-dev.
> > And it doesn't depend solely on gcc, since it can work with egcc as well.
> >
> While egcc can be used with libc6 to do development on select packages, it
> is not yet been used to successfully compile the distribution. It should
> continue to be the criterion for inclusion as a "c compiler" in the
> distribution. At this point in the development cycle this is not a good
> idea.
Having know immediate knowledge, I'll have to concede that it is possible
that gcc isn't appropriate for all development (although what besides the
kernel gcc can't handle hasn't become apparent to me).
> > > From my point of view on the subject is that it is the responsibility of
> > > the gcc and egcc maintainers to work out the details of providing both
> > > products.
> >
> > Yes, but they can't do that if libc6-dev specifically depends on a verion
> > of gcc.
> >
> Why? If you insist on removing gcc for "space" considerations, the force
> options in dpkg provide the mechanism, but there is no reason that gcc and
> egcc can't live together and play nice.
gcc and egcc do play nice. Excepting the fact that /usr/bin/gcc is always
gcc and not egcc (which makes modifying makefiles reasonably certain if
they're both insalled), they use alternatives to provide the cc symlink.
But libc6-dev doesn't play particularly nice with egcc by forcing gcc to
be installed as well.
> > > Just "because it can be done" doesn't make it a good thing to do. Everyone
> > > wants libc6 to manage problems with dpkg and the package of their interest
> > > without considering whether that is really the way to deal with the
> > > problem or not.
> > >
> > > As the libc6 maintainer I am unwilling to open up libc6 to complaints that
> > > are more properly related to egcc by providing the broader depends. At
> > > some time in the future my position will likely change, but right now I
> > > don't see any advantage to doing this and I see several disadvantages.
> >
> > In the end, it is your decision, but I hope you'll give it some more
> > thought. libc6-dev is useful with just egcc, so forcing gcc as well is a
>
> While I agree that there are areas where egcc is the preferred choice of
> compiler, that is not true for the complete distribution. Gcc is "the"
> compiler for development in Debian. While there are currently a few
> excepteions to this rule, these are not sufficient to have libc6 support
> their installation as a replacement for gcc. That will certainly change in
> the future, but the future isn't here yet.
True enough. Although "because it can be done" has been used as
justification for being more of a pain about a suggestion (the complaint
about being able to yank procmail out from under sendmail comes to mind).
Maybe my ramblings on this are foolish.
> > bug in my opinion. However, I won't make too large of an issue of it at
> > this time, although I can't promise I won't be louder about it in the
> > future.
> >
> The future would be a better time for this modification.
> > If you still disagree with me, I hope you might ask opinion on
> > debian-policy, but I won't fight if you decide to close this bug.
> >
> I have no problem leaving the bug open, as long as the severity is reduced
> to "wish list". The bug system is a good place for issues like this.
I guess I can settle for having this made into a wishlist item. I'm still
interested in hearing other opinions on the matter (since I have continued
posting this to debian-policy).
Scott
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: