DragonFly users List (threaded) for 2008-03
DragonFly BSD
DragonFly users List (threaded) for 2008-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Pkgsrc problems [ was: lang/python24 build problems]

From: ejc <eric.j.christeson@xxxxxxxxx>
Date: Wed, 26 Mar 2008 10:38:47 -0500

On Wed, Mar 26, 2008 at 9:46 AM, Hasso Tepper <hasso@estpak.ee> wrote:
>  * 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).
>  * 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.
>  * 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.

Well-stated issues!

>  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.
>  * "Our man/men in pkgsrc" (sry, mr. Greene ;).

This need is the key, IMHO.  Even if we have regular builds of pkgsrc
and people that will fix problems, we will still either need to have
people that can commit  those fixes or we need to branch pkgsrc as

>  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.

I feel this alternative is only slightly better than finding a
different package system, but that's an entirely different argument
which I'm NOT trying to start.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]