Re: ITP: haskell-dbus -- Haskell bindings for D-Bus API
Marco Túlio Gontijo e Silva <firstname.lastname@example.org> disse:
> Hi Rafael.
> Excerpts from Rafael Cunha de Almeida's message of Qui Dez 30 20:32:03 -0200 2010:
>> Marco Túlio Gontijo e Silva <email@example.com> disse:
>> > Is the package usable without libdbus headers? You probably want to add
>> > libdbus-1-dev as a dependency for libghc6-dbus-dev. For instance,
>> > libghc6-gtk-dev depends on libgtk2.0-dev.
>> It seems to work fine. It is curious to me that libghc6-gtk-dev would
>> depend on libgtk2.0-dev. Do you know why that happens? Being it a
>> haskell library, why would C headers be needed for anything?
> Well, it's not the headers that are required, but the symlinks for ld (check
> Policy 8.4). I installed your package without libdbus-1-dev and got the
> $ cat teste.hs
> import DBus.Connection
> main :: IO ()
> main = busGet Session >>= close
> $ ghc --make teste
> Linking teste ...
> /usr/bin/ld: cannot find -ldbus-1
> collect2: ld returned 1 exit status
Hm, I thought I had checked that, perhaps I removed the packaged from
the chroot and tested outside of it, who knows. Sometimes it feels like
when I don't see it I just can't see it. You're right, though, it does
depend on libdbus-1-dev. I'm fixing that.
>> > Also, I don't see much point in libghc6-dbus-prof recommending dbus, maybe only
>> > libghc6-dbus-dev recommending it is enough. Is dbus useful for building packages
>> > or for using the binaries produced? Maybe it can be a Suggests.
>> A binary produced with libghc6-dbus-dev is probably unusable without
>> dbus installed.
> Do you mean without dbus (the daemon and utilitaries) installed or libdbus-1-3
> (the shared library)? Sorry, I'm not familiar with dbus. Notice that if you
> include libdbus-1-dev in the dependencies of libghc6-dbus-dev, this will also
> include libdbus-1-3, since libdbus-1-dev depends on libdbus-1-3. If the only
> reason you're Recommending dbus is because of the share library, you don't need
> this recommendation at all.
I mean the daemon; without dbus daemon running, the library functions
are not really useful. What the library does is to use the daemon to
mediate interprocess communication. That is the reason libdbus-1-3
recommends dbus, I think.
But since libdbus-1-3 already recommends it, perhaps libghc6-dbus-dev
doesn't need to. Looking at libdbus-glib-1-2, which are glib bindings to
dbus, it doesn't recommend dbus.
>> However, let's take the
>> scenario of someone who, for whatever reason, have libghc6-dbus-dev
>> installed but not prof or dbus. Then, when that person is to install
>> prof, shouldn't he be reminded that prof recommends dbus? What's the
>> harm in having it stated both in prof and dev?
> There's no harm, but I don't think Recommends are used to remember the user to
> install a package at different times, but to declare a relationship between
> packages. I don't see a special relationship from libghc6-dbus-prof to dbus,
> I only see it between libghc6-dbus-dev and dbus.
I think libghc6-dbus-prof has the same relationship with dbus daemon as
libghc6-dbus-dev, after all, the application you'd want to profile
probably needs the daemon. However, seeing that libdbus-glib-1-2 doesn't
recommend it, perhaps we shouldn't recommend it at all either. I'm a
little confused about the whole issue, either way is fine to me. It's up
>> > Have you sent the patch upstream?
>> No. I was waiting to see if any of you would have comments on them.
> I think it's ok.
Will send them, then.
>> Me included? :-P
> No, thanks for that, corrected.
No need to correct it. I think it's cool when Belo Horizonte's local
team talk about library packaging and whatnot. Shows strenght of