[Pidgin] #2883: Not a bug, yet still a HUGE pain: no binary installed

[Pidgin]

#2883: Not a bug, yet still a HUGE pain: no binary installed
---------------------------+------------------------------------------------
  Reporter:  bezeek        |       Owner:        
      Type:  defect        |      Status:  closed
  Priority:  minor         |   Milestone:        
 Component:  pidgin (gtk)  |     Version:  2.1.1 
Resolution:  invalid       |    Keywords:        
   Pending:  0             |  
---------------------------+------------------------------------------------
Comment (by deryni):

 Real warnings/errors should cause an installer to stop in the middle, and
 I would bet that your portage tool even does this. The issue here is that
 there wasn't an error here.

 Putting the information about what was built at the end of 'make' is not
 at all the right place for it, putting it at the end of './configure' is
 and is why we do that. The fact that people don't bother reading their
 build logs is a flaw in the from-source package distribution system (or
 more specifically the flaw is that you need to at all).

 Splitting up the source packages would inconvenience anyone wanting to
 build all three pieces at once, require separate downloads to get them
 all, etc. Whereas distribution packagers are free to build as many
 packages as they want from the one tarball the fact that they don't is an
 indication of their lack of a desire to do so or their lack of belief that
 the users want such a distinction.

 The software is as friendly as possible currently, in fact that very
 'friendliness' is what caused you the problem in the first place. Had the
 configure script not allowed you to build just pidgin or just finch it
 would have died when it didn't find the GTK+ headers and your portage
 install would have failed.

 And no, users of binary systems would be unable to install the pidgin
 package by hand (using dpkg or rpm) if they didn't have the runtime
 dependencies, the tools would have complained about missing dependencies
 and failed. (Unless of course the user forced the install, but then that
 isn't anyone's fault but their own.)

 We can't fix it in any way that is at all simple or convenient, the
 distribution packagers on the other hand can and should create separate
 packages if their users want that ability. In fact for a source based
 distribution to do this it would just require them to not specify
 --disable-gtkui when building pidgin since when that isn't given it is in
 fact a configure failure to not have the GTK+ headers I believe.

 And in fact I believe Fedora does package libpurple, pidgin, and finch in
 separate packages and we have had people try to manually install the
 pidgin rpm and fail because they hadn't downloaded and installed the
 libpurple rpm first.

 So again, your issue here is really entirely a package issue and is
 something that should be taken up with the Sabayon/gentoo package
 maintainer. For the record the gentoo ebuild does output an info message
 if you fail to specify both gtk and ncurses USE flags, which message says
 "As you did not pick gtk or ncurses use flag, building console only."
 Equivalent messages could easily be added to explain what is being built
 if one so desired. But given the track record of gentoo users not to read
 anything related to their ebuild process (probably because it takes so
 long to build everything from source) I don't expect that adding any such
 message will help anyone much. Personally, I think the gtk USE flag should
 default to on and require being turned off manually, but I know gentoo has
 no ability to support such affirmative USE flags (as this was discussed at
 length when talking about the msn USE flag that used to exist) so there
 doesn't appear to be much they can do to help that either.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/2883#comment:6>
Pidgin <http://pidgin.im>
Pidgin