Re: pkg/42324: p5-XML-Parser should pkgdep on expat

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/42324; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Jens Rehsack <rehsack%googlemail.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, pkg-manager%NetBSD.org@localhost, 
gnats-admin%NetBSD.org@localhost,
        pkgsrc-bugs%NetBSD.org@localhost, dforsi%gmail.com@localhost
Subject: Re: pkg/42324: p5-XML-Parser should pkgdep on expat
Date: Mon, 16 Nov 2009 18:42:29 +0700

     Date:        Mon, 16 Nov 2009 11:42:51 +0100
     From:        Jens Rehsack <rehsack%googlemail.com@localhost>
     Message-ID:  
<df5c9d980911160242v5f2aa859q1c0c651ccb643ba1%mail.gmail.com@localhost>
 
 First, I see that obache@ has closed this PR (which was not mine)
 between your message and this reply - and that's fine (though it
 was not my PR) so this is just to conclude our small discussion...
 
   | What I meant to say: the pkgsrc package defines expat is required by
   | textproc/p5-XML-Parser.
 
 Yes, via buildlink
 
   | So either your packages are wrong, defect or sth. else.
 
 Not mine, but the latter, something else - which is that all binary
 packages on f.n.o are built with expat in the base system, and the
 textproc/expat buildlink3 does nothing at all.
 
   | You didn't attach your used pkg_add command line
 
 It wasn't me, but you're right, that wasn't there, but nor was it
 really needed, the pkg_add command line used changes nothing (it
 wouldn't even really necessarily indicate where the binpkg came from,
 and certainly not how it was built)
 
 Including a pkg_info on the (assumed broken) binpkg would have been
 more useful (hint for next time).
 
   | neither your uname -a output.
 
 But that was there, send-pr includes it - that's how I deduced it
 was a sparc package in question (incorrectly I see now, it was really
 sparc64, not that that makes any difference here).
 
   | Maybe the target you're using had an appropriate expat from the OS
   | installed on the machine where the package was created.
 
 Yes, exactly, that's just what I said - all the binpkgs are built with
 expat from the base OS, which is why both I, and obache, said that the
 fix is to install the xbase set, so expat will be there.
 
   | >  This is just yet another example of the "expat is used by the world
   | >  but is expected to be in the base system" that kills people using
   | >  pkgsrc modular xorg, instead of the X distribution sets.
   | 
   | I cannot follow this argument.
 
 I am not sure what else to say ... on NetBSD, the expat library is in
 the xbase.tgz distribution set (or x* for one of the x*'s anyway).
 
 All the binary packages available for download are built assuming a
 complete installation of NetBSD on the target system - that includes the
 x* sets, but also the text set which also sometimes causes people
 problems (they don't believe they need it, but pkgsrc just assumes it
 exists).
 
   | >  The answer is to install xbase (or whichever of the x* sets expat is in)
   | >  and then it will be present.
   | 
   | Neither that.
 
 But that's where expat is to be found?   Another fix would be to rebuild
 everything from pksrc, and not use binpkgs at all, but if you're going to
 tell everyone to do that, what's the point of providing binpkgs for
 people to download ?
 
   | >  Longer term, we absolutely need a better way (and moving expat from x*
   | >  into base just solves one instance of the problem - a common instance,
   | >  but just one).
   | 
   | I don't agree. I don't need expat everywhere - so why it should be in base?
 
 I did not say it should be in base, I have said before, I have no
 opinion on that.  I would say that what you, as an individual need, or
 don't need, should not influence what TNF does though - what matters is
 what is best for most people.   I don't need any of the kerberos noise,
 yet that's in base, but I'm not about to tell (or even ask) TNF to remove it,
 just because I don't need it.
 
 But read again what I did say ... that is that we need a fix to the problem
 of depending upon stuff that is just "assumed to exist" by pkgsrc binpkgs.
 
 For pkgsrc (src), it isn't such a big problem, if something is missing, the
 pkg fails to build, it might be nice to automate things, but at least it
 fails in a way that it is pretty easy to see what went wrong.
 
 But for binpkgs, they apparently install just fine, but they just fail to
 work properly, with (usually) fairly obscure messages, leading to PRs like
 this one.
 
 One (short term, pre-syspkg, assuming syspkgs ever happen) fix might be
 to have a pseudo dependency installed in all binpkgs upon a pseudo pkg
 named after the base set (each base set) upon which the binpkg depends.
 So, this one could depend upon
 
        base-sets-xbase-*
 
 or something like that, implying that that base set (xbase) needs to be
 installed.  pkg_admin could look to see what base sets are present (by
 selecting one file from each,a nd testing for it) and add in those
 dependencies...   (pkgsrc could perhaps even "guess" which base sets to
 add as dependencies, depending upon what USE_TOOLs are selected...).
 
 Or something like that...   (yes, this is hand waving, not a solution)
 
 And last:
 
   | And what do I do on machine which do not have expat in base?
 
 Yes, agreed, which is why just moving expat from xbase to base doesn't
 solve this problem, or not for a long time into the future (and even then,
 only on NetBSD, other systems may not all do the same thing).   If anything,
 doing that probably might make the problem worse, as no-one using
 current would ever see it, only those on older base systems.
 
 That, or itself doesn't mean that moving expat into base isn't the
 right thing to do, that's an entirely different question (once again,
 no opinion on that from me) just that using these pkgsrc (binpkg) problems
 as the motivation for that would be misguided.
 
 kre