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

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

    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