Wait, there's http://pike.ida.liu.se/download/pub/pike/beta/. Neat. But there's no 7.7 there.
No, and there never will be. Eventually there will be 7.8 betas. The development tree doesn't get releases. As soon as we have finished negotiating the feature set for 7.8, 7.7 will be moved to 7.8 and a 7.9 branch will be created.
I just wanted to inject a comment or two into this conversation, as it seems like a good point in time considering the in-flux nature of debian packages. I'm not a debian user, but I've got a number of modules that seem to either be a) packaged for Debian or b) popular, relatively speaking.
The first problem is that on a fairly regular basis in the past, external module building using "pike -x module" or "pike -x monger" has been broken in the Pike distribution. When reported, Marek was pretty good about fixing the problem, but it still was a hit-or-miss proposition for some reason. I think that really works against having a good reputation. What's the best way to ensure that the debian packaging system doesn't break this functionality? I'm guessing that the simple addition of a testsuite won't work, as it doesn't operate on the installed pike. Does debian have something that can help solve this problem so that it's not a manual task?
The second problem is that I often get reports of problems with modules not working with the debian package, and on more than one occasion, it's been because the package provided a non-stable-stable build of Pike, such as 7.6.93, that included a bug not present in official releases. Actually, from what I can tell, that happens pretty regularly. Is there really good reason why non-official- version packages are made like this? It seems to me that a new official version of Pike is made fairly regularly, so I'm not sure I see the benefit of this particular practice. Again, having users experience bugs like that don't exactly help the reputation of the product.
Can anyone shed any light on these two items?
Bill
Not a direct response to either question, but one thing which may help make pike -x module more likely to work (in both Debian builds and our own) is to make as many of the Pike native modules as possible use the same system. I think that is on a todo list floating around somewhere.
It's on there. The goal is to build as many of Pikes included modules as possible with pike -x module for 7.8.
If you send the summary of our last brainstorm/planning session I'll make some more detailed descriptions of what we want to do.
I intend to do my best to ensure that things don't break, but I need to fully understand how modules are meant to be built, and I need some to test with. I guess I can download a few using pike -x monger. Then I'll probably have to test building and installing those modules manually before releasing a new Debian package.
We need a Pike Policy for Debian.
For starters, third-party modules can't be installed in the versioned modules directory or such packages would have to be rebuilt every time pike is upgraded. If a module is built with Pike 7.6.x, it will work with all later 7.6 versions, whether it's a C Pike module or a Pike Pike module, right? We clearly need counterparts to /usr/lib/perl5 and /usr/share/perl5 for packaged modules, and dynamic_module_makefile should support $DESTDIR.
Locally built (not packaged) modules should be installed in one of the directories in /usr/local, however. Maybe use the install_local target for that, and patch local_module_path in module.pike to e.g. /usr/local/lib/pike7.6/site_pike.
The second problem I think I already addressed: Only stable Pike releases should be uploaded to sid, possibly with a few isolated and well-tested patches.
pike-devel@lists.lysator.liu.se
-
H. William Welliver III -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum -
Magnus Holmgren, exim.org ＠ Pike developers forum
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum