|2009-02-19 13:19, comment #16:|
You are really becoming opaque to any argument.
When you say:
"The proposal to use the OS supplied libAfterImage when _possible_, does not
imply a regression in functionality. "
Not only it is a regression in functionality, but the graphics output is totally wrong!!!
You care only to get a successful build, we care about the result.
|2009-02-19 13:12, comment #15:|
Let's keep it civil. No reason to do name-calling.
I think you're right when you say "We are on different wave-lengths.", but for different reasons. I put the current bug report in, because I think when it is possible to use the stock libAfterImage, the option should be re-enabled in the configure script. That's all.
The reasons why I think is a good idea to use the stock libAfterImage are those outlined by Sebastian.
Now, using the stock libAfterImage does not preclude using a built-in version of the same library (as it is done for pcre, freetype, and others). The default would be left as it is i.e., use the built-in. If a user decided to, and has a proper version of libAfterImage, then she can use the OS supplied library. But it is her choice.
When a user files a bug report/complaint/... regarding libAfterImage stuff, you can always ask which version the user used: OS supplied or built-in. The information is available via `root-config --features'. If the user used an OS supplied libAfterImage, then the bug can be redirected to Sascha or the OS distributor directly.
The issue here is choice. If ROOT can use the OS supplied libAfterImage why not let the user have that choice? ROOT just need to decide what "ROOT can use the OS supplied libAfterImage" means - most likely some release number of libAfterImage. This is done for pcre, freetype, and others already.
I will of course continue to submit security bug reports and other feature requests that I (or others) find reasonable and useful, so that ROOT may evolve to the benefit of all users. I'll of course collaborate with you as best I can to solve any such issues.
Note, that libAfterImage is a little funny in some distributions, in that the binary is built not from the source package supplied by Sascha but via the afterstep source package. So there's another layer of indirection, which means that security and other fixes done by the OS distributor has another layer to go through before the patch ends up in Sascha's libAfterImage.
The proposal to use the OS supplied libAfterImage when _possible_, does not imply a regression in functionality.
|2009-02-19 10:59, comment #14:|
I am sorry to see that there is no point in discussing this argument with you. We are on different wave-lengths. You are becoming an international bureaucrat who cares only about security and packaging issues, certainly important issues. I care about the quality of software and functionality. I do not want users to report wrong behavior with a ROOT version incorrectly linked with a wrong or obsolete version of a software system. We have the permission from Sacha to distribute his code withing the ROOT SVN and source and binary distributions. The two projects are evolving in good syncrony. We garantee that our distribution works correctly on all Linux distributions, but also on all macos distributions and windows distributions with the 32 and 64 bits variant (important for libAfterImage). If you find security problems, please report them, they will be fixed, this is important. It is likely that the most recent versions have less security issues that one year or two years old versions.
I hope that I have been clear this time, so please stop making proposals that are not acceptable for us.
|2009-02-19 10:40, comment #13:|
First of all, I think we should leave this a bug as long as ROOT cannot use stock libAfterImage. That does not mean that the bug should be resolved as soon as possible.
I fully understand that ROOT needs some experimental features of libAfterImage currently not available in any release. As long as that is the case, it is fine that ROOT uses the built-in libAfterImage.
However, at some point in the future, ROOT will presumably not need experimental features of libAfterImage (either because libAfterImage stabilised or ROOT are not using experimental features any more). At that time, this bug can be closed and everyone is happy.
René said: The version of libAfterImage that we ship with ROOT is the latest possible version from the author.
Unfortunately, that version of libAfterImage isn't available as a release, and therefore not available in OSs. There's no two ways about it: ROOT is using a experimental development version of libAfterImage as it is now.
If the upcoming libAfterImage release (1.19 or 2?) is good enough for ROOT, why not accept using this as an external library, and only in the case that the OS version of the library is older - use the built-in version (as done with pcre, and others).
Security fixes and such done by distributions are not trivial issues. More than often, a security bug is found in the distribution before it is found by upstream developers and source code users. That's because most distributions does code auditing and has wider use scope than most developers could ever hope for or do themselves. I've personally filed a handful of security bugs against ROOT (and in particular XRootd) that came from Debian. Also, after the release of Debian 4 (lenny) this past week, ROOT is now exposed to a much larger user base than before, and you can expect to get many more security fixes.
René wrote: I was hoping that Christian will be able to solve the distribution problem in a timely manner saving communication time on both sides.
I cannot solve the `distribution problem' of libAfterImage. Sascha needs to release his code (as a proper release) before a newer libAfterImage can propagate to the distributions. And, as I'm not the maintainer of any libAfterImage package, I cannot event take upstream patches and port them to the distributions. Sascha has to release first. According to Sebastian, that will happen soon, which is very good.
The point of this bug report is to remind us that once the newer libAfterImage is released, so that ROOT can use the stock libAfterImage, we should re-enable that feature in the ROOT build system. The reason why this is a bug, is as Sebastian argued, that
- It's a major security issue.
- Distributions dislike code duplication.
- Ease of maintenance.
- Exploit fixes done by distributions.
But do note, that the bug is classified as a "feature request" - not a true bug. It is a kind reminder that we can do better.
These are not, as René phrased it, "badly wrong" reasons. These fundamental principles for good software distribution. René might not care too much about system integration and distribution of code - after all, why should he, his job is to make ROOT only - but others do care, and we say that this is a problem and there's a simple solution so why not pursue that?
Hopefully, Sascha will soon release a new version of libAfterImage, and hopefully the distributions will pick up this soon. Then, we can re-enable the option in the "configure" script, and the bug is closed. However, for the bug to remain closed it would be good if ROOT could refrain from using too many experimental features in 3rd party packages in the future. It would make life easier for everyone around.
|2009-02-17 19:18, comment #12:|
Some users actually do not have "obsolete software" and libafterimage-1.18 is not "years old": june 2008; also some distributions add extra patches not included in root latest svn.
I understand ROOT needs newer than 1.18 libafterimage features.
If that helps, Sasha just told me he's planning a new release of libafterimage in the not so far future. It could be worth making it a minimum requirement for ROOT when he's done (meanwhile, the problems mentioned in the "badly wrong" arguments remain).
Really, I've maintained more than 200 packages in Gentoo Linux and always had to fix more bugs and security issues with the ones shipping built-in libraries.
|2009-02-17 17:53, comment #11:|
Just a clarification. All your arguments are badly wrong.
The version of libAfterImage that we ship with ROOT is the latest possible version from the author. All other versions are years old, full of errors and totally unacceptable to run with ROOT graphics.
If you want to run with obsolete software, use the versions distributed with the OSs,
but do not send any complaint to the ROOT team.
I was hoping that Christian will be able to solve the distribution problem in a timely manner saving communication time on both sides.
|2009-02-17 17:29, comment #10:|
I agree with Christian on this one. Having to build libafterimage within root has the following drawbacks:
- code duplication, other packages need libafterimage too
- security issues: libafterimage shipped with ROOT has builtin-gif and other build problems
- easier updates
- take advantage of distribution patches of libafterimage if any
- one less thing to maintain in root.
If you have a good collaboration with Sasha, why not convincing him to release a newer version of libafterimage that will fit ROOT needs.
If you really don't want to use a stock libafterimage, I still suggest to at least remove the "--with-builtin-ungif" in
graf2d/asimage/Module.mk and remove the "--enable- builtin-afterimage" option in the configure script which is forced anyway.
|2009-02-17 16:23, comment #9:|
I am surprised by your answer. Are you becoming lazy ?
We have a splendid cooperation with Sascha vasko, the developer of libAfterImage. Using what you call the "stock" version would be a major step backward and a pain in the neck. We will forward the problems to you. What is wrong in using the native libAfterImage
that we ship with ROOT?
So PLEASE do not recommend this solution. Fix the problem where it has to be solved instead.
|2009-02-17 16:11, comment #8:|
Please leave this bug report open until such a time when you can actually use a stock libAfterImage. At some point, libAfterImage should stabilise enough that ROOT will not need experimental features.
|2009-02-17 14:20, comment #7:|
Yesterday we took the latest fixed from Sasha. We need them in ROOT. I do not see an other way than continuing as we do now with libAfterimage. Using and old version will end up with wrong pictures and users will complain. So I close this report.
|2009-01-20 14:45, comment #6:|
I understand the looking good part. What about security issues?
One solution would be to modify graf2d/asimage/Module.mk to disable building libraries such as ungif.
Relying on a shipped library is never a good idea not only for security reasons. Why not trying to convince Sasha Vasko to release a version that ROOT could rely on?
Also, if you really want to keep a builtin libafterimage, the ROOT configure script should be modified to remove the builtin-afterimage option so the user doesn't get confused.
|2009-01-20 12:10, comment #5:|
We rely on the libAfterImage CVS head from Sasha Vasko. For instance I have worked last week with Sasha on fixing a bug about Markers Drawing (the markers with circular shape did not work). So if you use the system version you will get these ugly markers and the only way to have them looking good will be to use the one in ROOT svn.
|2009-01-19 21:46, comment #4:|
This would be nice to depend on the system libafterimage. libafterimage is now at 1.18. Is this version suitable?
The current configure script still doesn't work with a system libafterimage.
Also, the root builtin libafterimage uses at least builtin libungif which has security issues usually fixed in system libs.
|2008-03-04 15:48, comment #3:|
Forget the built-in libAfterImage. ROOt SVN trunk can only work
with the latest developments by Sasha. We are expecting even more fixes from him in the coming weeks/months.
|2008-03-04 15:45, comment #2:|
Hi René et al,
Until libAfterImage is properly released with the sync in place, I think this bug should remain open - at least until such a time when the configure script can detect the new version automatically. If this is the case, then the bug can be (re-) closed. Fons, how's the situation: Can "configure" auto-detect a properly patched system libAfterImage at this time? Is "--enable-builtin-asimage" re-enabled?
|2008-03-04 10:15, comment #1:|
The version of libAfterImage in the ROOT SVN trunk is in phase
with the CVS version of the author Sasha Vasko.
|2007-11-02 00:10, original submission:|
It seems that all the features of the ROOT shipped libAfterImage is available in stock libAfterImage 1.15. Please consider using this version, and re-enable the use of system libAfterImage if it is this version or better. Thanks.