일부 성의없는 GNU Open Source 그룹

어떤 글인지 읽고 싶었지만 링크가 연결이 안되는군요.

저는 이러한 것들은 버그레포트를 많이 하는 편입니다.
그러나 프로그램이나 소프트등은 그나름대로 폴리시가 있습니다.
그러한 것에 해당이 되는 것을 바꾸어야한다라든가 버그레포트라고
해서 올려도 호학호락 받아 들여지지는 않습니다.

특히 GDBM과 같은 라이브러리는 파이선을 비롯해 펄등 기본 언어나
기본 시스템에 많이 사용이 되어 메이크파일이나 정의등의 기본치는
하나의 정책과도 같은 것이기 때문입니다.

여기에서 NDBM은 이전에 버클리DB라이브러리도 호환이 되기도 했고
해서 버클리DB의 구버전을 사용하면 되기는 합니다. 그러나 GDBM이
이 호환용 라이브러리를 추가함으로서 다른 소프트의 개발진들도 이전의
버클리DB를 사용하지 않고 GDBM을 사용하기 시작했죠. 그러나
최신 버전의 GDBM에서는 일방적으로 라이브러리의 이름을 변경하고
NDBM/ODBM의 서포트가 되지 못하도록 메이크파일을 변경시켰습니다.
이것으로 인해서 언어 쪽의 펄, 루비 파이선등의 진영에서는 지금도 고심을
하고 있는 것입니다. 사실 NDBM/ODBM은 구버전 버클리DB를 사용하는
것이 훨씬 빠르고 안정적입니다.

이것은 선마이크로시스템등에서 각종 언어를 컴파일해서 인스톨하고 할때는
아마 리눅스보다도 더 까다로와질 것입니다.

여기에서 문제가 되는 것이 이미 정책이 GDBM쪽을 사용하기 시작해 방대한
빌드 쉘스크립들이 작성이 되어 있는데 이러한 스크립들을 일일히 조사해서
각 언어 사이트에 모두 패치파일을 레포트해야하고 또 리눅스 벤더에도
이렇게 기본 GDBM라이브러리를 작성해야한다고 알려주어야만 이 문제가
근본적으로 해결이 되는 것입니다.

이런 것들을 일일히 할정도로 개인이 시간적인 여유는 없을 것입니다.
이럴때 개선할 수 있는 가장 빠른방법은 제작자에게 직접 메일을 써서
변경되여야한다고 설득하는 길밖에 없다고 생각이됩니다.

그래서 저는 가능한 위와 같은 방법으로 직접 제작자에게 메일을 보내는
방법으로 레포트를 합니다. 거의 대부분이 "It should be...."라든지
"It must be...."라는 내용으로 답변이 옵니다. 그래서 항상 느끼는
것이 정말 똥고집들..., 하면서 제자신의 길을 걷고 도움을 구하는 이에게는
제 방법이나 패치를 제공하는 것입니다.

이러한 이유로 올해에는 제 자신만의 리눅스를 만들려고 시작을 했습니다.
이전의 운영시스템 개발도 함께하면서 랑데브라는 코드네임으로 일본에있는
20여개 관련회사의 개발자들과 저의 회사가 산학헙동으로 출발한 회사이기
때문에 관련 대학교 대학원생들과 개인적으로 메일링리스트를 만들어서
시작을 했습니다. 이것을 시작한 이유도 위에서 이야기한 GDBM의 내용과
비슷한 것들을 여러 리눅스 디스트리뷰션에서도 느껴왔기 때문입니다.

네 맞습니다.

그러나 libgdbm_compat을 사용해서 빌드해도 여러 문제에 직면할 것입니다.
이 부분에 대해서는 이미 많은 개발자들이 논의한 상황인데도 아직도 질질 끌고
있다는 것에 대해서 조금 불만을 가져왔고 개발자에게도 충분히 여러 언어들을
빌드하고 테스트해서 문제가 있다고는 알렸고 패치도 제공했습니다.

그리고 이부분은 현재 펄 새버전이나 파이선등의 빌드에서도 문제가 되고
테스트를 통과하지 못해서 걸림돌이 되기도 합니다. 그리고 이러한 언어를
개발하고 하는 사람들은 다른 라이브러등에 대해서 신경을 거의 안씁니다.
그것은 라이브러리를 개발한 개발자의 영역이라고 생각해서 인지 별로
타치를 하지 않으려고 하고 현재 이것에 대처하기 위해서 나온 하나의 방안이
펄에서의 NDBM/ODBM 을 이제는 제거하자는 단순한 해결책입니다.
버그 레포트만 뉴스그룹에서 계속해서 올러올 뿐입니다. 또 느끼는 것인데
많은 개발자들이 많이 말하는 것중에 자신의 시스템에서는 잘되다라고 하는
것입니다. 자신의 시스템에서는 잘된다고 하면 다른 것들은 별로 신경을
안쓰는 경향도 있습니다. 여러 라이브러리가 있고 버전별로 다른 결과가
있다고 해도 그러한 것들을 일일히 체크하고 그러는 개발자는 그렇게 많지
않다는 느낌입니다. 다만 버그가 올라오면 그러려니 아니면 라이브러리를
개발하는 사이트에서 수정을 하겠지 하는 생각을 가지는 것인지 그 사이트의
개발 폴리시를 존중해서인지 알길이 없습니다.

libgdbm_compat 부분에 NDBM/ODBM관련 함수들이 들어가 있습니다만
실질적으로는 libgdbm에도 필요한 함수들이 들어가 있습니다. 그래서 두개다
링크를 걸어서 작성을 해야되는데 이상하게도 libgdbm 하나에만 링크가
걸리게 되는 경우가 있기도 합니다. 시그윈에서는 아주 잘되는 모양인데
리눅스에서는 문제가 되고 있고 유닉스에서도 문제가 되는 모양입니다.
또 여기에서 기존 언어빌드 시스템이나 여러 시스템의 경우에는 그 스크립이
정확하게 잘 작동이 될 경우에는 수정을 않하는 경향이 있습니다. 뭐 단순히
이것을 수정해서 빌드하면 되겠지 하고 생각하는 사람들도 있을지 모르지만
그렇게 단순한 문제는 아닙니다. 아직도 일부 10년전의 빌드스트립이 그대로
펄에서 사용이 되고 있는 부분이 있다는 것을 보면 알 수가 있을 것입니다.
한번 수정하게 되면 이미 지금까지 배포되고 개발해온 모든 버전의 서포트를
포기해야만 하는 경우도 있기 때문입니다.

일방적으로 다른 여러 곳에서 사용되고 있는 라이브러리를 바꿔놓고 그것으로
인해 일어나는 수많은 버그레포트들이나 트러블에대해서 너무 방치하고
있다는 것이 조금 화가 난것입니다.

해결방법은 libgdbm과 libgdbm_compat를 하나로 통일해 libgdbm.so를
생성하고 이것을 libndbm.so파일로 시스템 링크를 걸면됩니다. 그러나
여기에서 또 문제가 되는 것이 라이브러리 파일경로는 하나 뿐인데 기존의
libndbm이 존재할 경우도 있다는 것입니다. 이전에는 libndbm 대신에
libgdbm을 링크를 걸어서 컴파일해라 이런식의 해결 팁이 많이 있었는데
변경이 된후로부터는 이 방법으로는 이제는 안됩니다. 패치해서 라이브러리를
다시 빌드하지 않으면 안됩니다. 그래도 여간한 리눅스 시스템의 컴파일과
GCC의 지식이 없으면 쉽게 해결되고 하는 문제도 아닙니다. 이유는 이미
기존의 라이브러리가 /usr/lib에 있기도 하고 헤더파일도 어느 것이 로드되어
컴파일 되는지 일반 사용자는 바로 알수가 없기 때문입니다.

아시다시피 이러한 기본적으로 시스템에 들아가는 라이브러리는 한번 정책이
바뀌고 이름이 바뀌게 되면 어마어마한 혼란을 가져옵니다. 버클리DB 역시
버전이 오라가고 하면서 이러한 문제가 많이 있었다고 생각합니다. 이 DB는
MySQL에서도 사용되는데 기존 DB3버전을 사용해야만 컴파일이 됩니다.
아마 리눅스를 인스톨하면 DB와 GDBM라이브러리가 없는 시스템은 없을
것입니다. 그리고 센드메일이나 아파치 펄 OpenLDAP등등 사용되는 곳이
한두군데도 아닙니다. 때에 따라서는 여기에서 스피드를 올릴때 GDBM아닌
NDBM/ODBM을 사용하는 엔지니어도 있습니다. 또 NDBM라이브러리에
DB1.8버전대 라이브러리를 사용해서 퍼포먼스를 내고 하는 자도 있습니다.
이 방법으로 하면 GDBM보다는 한참 빠른 성능을 내는 시스템을 구성하기도
하는가 봅니다.

이러한 문제가 계속 되고 있었고 다른 언어 사이트 메일링 리스트등등에서
제가 이야기 한 부분에 대한 내용을 검색해보면 많이 볼 수가 있을 것입니다.
일부 황당한 것은 이미 해결된 사항입니다 라고 완전히 종지부를 찍고
더이상 이 부분에 대히서 커미트를 부정하는 곳도 보게됩니다.

이러한 이유로 조금 더 신경을 써서 변경을 했다면 쓸떼없는 시간을 많이
줄이고 그 시간들이 다른 곳으로 쓰여져 더 유익하게 사용되지 않았았을까
하는 취지에서 글을 오린것입니다. 세계적으로 이 시간을 계산하게 된다면
어마어마한 시간이고 이러한 관건은 현재의 오픈 소스 개발에서 인류적인
막대한 손실이라고도 생각을 하기때문입니다.