Pkgsrc problems [ was: lang/python24 build problems]

[Thomas E. Spanjaard]

Hasso Tepper wrote:
At least some of us agreed that pkgsrc isn't shiniest package management 
system - upgrade is real pain etc. This is not about these technical 
issues. Pkgsrc is IMHO the best option we have at the moment, but ...
Pkgsrc is virtually the only option we have at the moment.

AFAICS DragonFly support in pkgsrc have been mostly Joergs' project. 
Thanks to him we have what we have now. But his focus has shifted away 
from DragonFly AFAICS (no problem, it happens all the time with people; 
it's called life, evolution etc) and DragonFly specific issues in pkgsrc 
don't get enough love any more. More specifically:
Both Joerg and Jeremy; and prodding either of them seems to have good 
results. Also, you can try prodding Johnny Lam.

* Patches sit in NetBSD bugs database too long. Nobody seems to confident 
  enough to commit patches or just don't care enough or patches remain 
  just unnoticed etc. #36978 is good example, but there are others 
  (net-snmp with this fix doesn't build any more, btw, but I'm also afraid 
  that it isn't net-snmp issue now, but perl).
This is a problem of the MAINTAINER not being active enough as well.

* Even if patches go into pkgsrc, they are not pushed to upstream. While I 
  know there are a lot of people out there who don't think about it as 
  important thing, it's extremely important IMHO.
Agreed; the relative utopia would be to have no need for patches at all. 
But this is harder to get right, due to disparate release schedules for 
different projects, etc.

* Pkgsrc isn't tested enough _before_ freeze and release. The result is 
  that issues is discovered after pkgsrc release and fixes will be 
  available for wider user community in _next_ release (the very same 
  python24 issue is good example). Next release has its' own issues etc.

So, IMHO we need two things:

* Regular builds of pkgsrc HEAD on both our stable and HEAD with info 
  about failures made available for community. I think that many of us 
  (including me) can take a look at logs and try to fix issues. The 
  important point is that we should try to catch as much of bugs as 
  possible _before_ release.
Nice idea, except doing full bulk builds of pkgsrc does that its fair 
amount of time. If you have a multicore machine, you can run multiple 
builds in parallel on vkernels to make builds run faster, but even still 
you need a beefy CPU, lots of RAM and not just a single disk, but a fast 
disk array to power the build. SSDs would be ideal :).

* "Our man/men in pkgsrc" (sry, mr. Greene ;).
We already have people who care enough about DragonFly on pkgsrc, but 
they're not enough, I agree; it's a lot of work to keep an eye on all 
packages, and staying focused on fixing issues instead of running into 
annoyances with pkgsrc all the time also requires dedication. If some 
people started flooding pkgsrc GNATS with patches for DragonFly, I'm 
sure commit bits won't take long to arrive.

There is at least one laternative as well of course - to branch pkgsrc 
(fork isn't correct term here IMHO). So, we could fix our issues in "our 
pkgsrc stable", build our packages from this "branch" etc. While 
recommended by some people, I personally don't like the idea much though.
Like what happened to dfports? We don't have the manpower to maintain a 
respectable package repository ourselves.

Opinions? Or more importantly - volunteers?
My opinion comes for free, but volunteering... I don't think I can 
commit the time to become an active pkgsrc developer :).
--
	Thomas E. Spanjaard
	tgen at netphreax.net
	tgen at deepbone.net

Attachment:
signature.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: OpenPGP digital signature"
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20080326/931b1653/attachment-0021.obj>