Comment 4 for bug 336634

On sam, nov 26, 2005, Loic Minier wrote:
> (we had this discussion on IRC already)

 More bits, the new information here is that people involved in
 pkg-config think that using headers of another lib in your headers
 means you have a public dep on this other lib, and that will result in
 an ELF dep. It also clarifies that the improvement is because of the
 removal of the static flags which caused dynamic deps, and won't
 improve gtk-ish/gnome-ish libs.

21:55 < lool> vorlon: if you have two minutes, could you please send a word to
              <http://bugzilla.gnome.org/show_bug.cgi?id=322240>?
21:57 < Q_> lool: Still waiting for a fix so I can build gtk-sharp2.
21:58 < lool> Q_: well, I'm still waiting for a consensus to be reached, I
              think the stronger opinion was to add only -Is from private fields
21:58 < lool> but this is all too borderline for me to take the decision, one
              way or the other
22:00 < Q_> Mithrandir: Around?
22:01 < lool> Q_: BTW, I filed #340904 to track the story
22:02 < vorlon> lool: what word are you looking for? :)
22:03 < lool> vorlon: the kind of word carrying final-person opinion (eg where
              I don't relay opinions from third parties :)
22:04 < lool> this is really a pkg-config design question for me, and the
              technical implementation is not the problem, so I'd rather have
              you or Mithrandir or who ever feels he knows what is correct
              express himself there, than me
22:05 < vorlon> lool: well, Mithrandir and I seem to disagree here on what the
                correct design is, and one of is is pkg-config upstream whereas
                the other is not. :)
22:06 < Q_> lool: And nothing happened to it yet.
22:06 < lool> vorlon: exactly, and since I'm not strongly convinced one way or
              the other, I can't represent either party in the discussion O:-)
22:08 < vorlon> lool: well, I don't see much point in trying to argue the
                pkg-config design details in a bug report against *vte*: that's
                not fair to the vte maintainers, and it's not a very effective
                means of getting pkg-config changes made. I don't feel
                strongly enough about this corner case today to argue it at
                *all*, really.
22:10 < lool> vorlon: well, I wanted your take on the situation to vte's
              upstream which is now victim of the change too, I can try to
              explain the situation myself to vte's upstream, but I will be
              short of arguments what ever camp vte's upstream picks
22:10 * lool bravely goes telling vte maintainer that we've pulled them in a
          mid-term problem
22:12 < Mithrandir> Q_: yes
22:13 < vorlon> lool: I don't think vte upstream is going to pick the "I'll let
                my software continue to be broken" camp
22:14 < lool> exactly
22:14 < Q_> Mithrandir: So, did you have some time to think about the problem,
            and the best way to solve it?
22:14 < dilinger> i wish i could admin some AIX machines
22:15 < dilinger> i bet it would cause me to get a lot less frustrated when i'm
                  faced w/ crap like redhat and suse
22:15 < Mithrandir> Q_: oh, the requires.private stuff?
22:16 < Q_> Mithrandir: Yes, the -I
22:17 < Mithrandir> 02:39 < jamesh> Mithrandir: about your pkg-config question:
                    no. If a package is a private dependency, then its
                    interface shouldn't be exposed at all.
22:17 < Mithrandir> 02:39 < jamesh> Mithrandir: so the -I flags shouldn't be
                    included
22:18 < Q_> You mean we should try to convince jamesh?
22:18 < Mithrandir> I'm somewhat inclined to agree with jamesh, but neuro had
                    some comments which went in the other direction. I think
                    I'll have to sit down and look at what can go wrong in the
                    different situations.
22:18 < Mithrandir> yes, if you convince jamesh, I'm ok with it. He knows a
                    bloody lot about how pkg-config works, is supposed to work
                    and why it works that way.
22:19 * lool wishes for a clearer definition of the goal of the
          requires.private header
22:21 < vorlon> lool: well, this opinion from jamesh is consistent with
                treating glib as a *public* dependency of gtk just because
                software can cheat and use glib API calls directly when only
                including gtk. :P
22:23 < Mithrandir> vorlon: yes, but what if glib was a private dependency of
                    gtk? Would it be ok to expose, say, gchar*?
22:24 < Mithrandir> (or better, gchar, since a pointer is always ok)
22:25 < vorlon> Mithrandir: if gchar is used in the gtk headers, yes. :)
22:25 < Q_> Mithrandir: A pointer isn't any better.
22:25 < vorlon> Q_: it's legal to have pointers in C that you don't have enough
                information to be able to dereference.
22:26 < Mithrandir> Q_: sure it is, as long as you don't expose the typedef.
22:26 < Mithrandir> so you can't dereference it, as vorlon says.
22:27 < Q_> vorlon: But you still need to say that it's a type.
22:28 < Mithrandir> Q_: a struct would be a better example and then you can
                    just say struct foo; and use struct foo* without any
                    trouble.
22:28 < Q_> so something like "struct foo *bar;" works, "struct foo bar;"
            doesn't.
22:29 < Q_> But at that point you don't even need the include in the first
            place.
22:30 < lool> vorlon: if you look at private/public deps in this way, then my
              feeling is that this clarifies deps for static linking, but won't
              help reducing dynamic deps
22:31 < vorlon> lool: ?
22:31 < Mithrandir> lool: and we want to reduce dynamic deps. Possibly not
                    perfectly (stuff linked to gtk will still link to glib,
                    since it's an actual public dependency), but better than
                    today.
22:31 < vorlon> lool: which way?
22:32 < lool> vorlon: in the way of jamesh proposing to treat such interfaces
              as public deps
22:32 < lool> anyone minds if I copy paste this log to the bug?
22:33 < Mithrandir> lool: feel free
22:33 < lool> Mithrandir: true, it's just sad this helps so little in the case
              of gtk-ish libs
22:35 < Q_> Anyway, I think the point was if that gchar is part of gtk headers,
            and gchar changes in such a way that it breaks gtk, and so also
            things linked to gtk, that both got an api change, and both should
            do an soname change.
22:35 < vorlon> lool: it's less than ideal, but there are still *some* lib
                savings.
22:36 < Mithrandir> I would like to accomodate the gnome/gtk model of handling
                    headers, though.
22:36 < Q_> And that might not be something the gnome people would like to do?
22:37 < lool> Q_: well they included vorlon's patch quite rapidly
22:37 < lool> Q_: I suppose they will use any pkg-config coolness you explain
              them to use
22:38 < Q_> lool: I think they don't want to and change all their sonames
            because something in glib changed.
22:38 < Q_> s/to/to go/

--
Loïc Minier <email address hidden>