On 05/04/13 15:31, Tom Browder wrote: > On Fri, Apr 5, 2013 at 7:38 AM, Jordi Sayol <[email protected]> wrote: >> On 05/04/13 13:23, Tom Browder wrote: >>> On Wed, Mar 27, 2013 at 10:51 AM, Jordi Sayol <[email protected]> wrote: >>>> On 22/03/13 19:52, Tom Browder wrote: > ... >>>> There are at least three basic things to make brlcad deb to accomplish >>>> with Debian rules: >>>> - split into multiple deb packages >>> How do you see that split? > > I wasn't very clear, Jordi. I meant to ask is that something like: > > two debs per lib (lib and lib-dev) # over 40 unique libs => 80+ deb packages > > And are the bin files their own deb?
Yes, that's correct, and documentation, split in html, pdf, etc. and then by language too... This is not a joke, is the Debian style, and is a lot of work. Anyway, before this step there are two things to fix: "/usr" base directory and use all shared libraries from system instead of built-in ones. This will be a giant leap too. As this is a big change on deb package, I propose you, and Christopher as well, to create a parallel deb building process by coping of "misc/debian" into "misc/deb-testing" and "sh/make_deb.sh" into "sh/make_deb-testing.sh", and you developing everything on it, and I'll keep the "stable" deb version till your fork was mature enough. What do you think about? > >> A lot of work, but mandatory to include brlcad into Debian repositories, >> not my decision but the Debian members. > > Can you point to the Debian document discussing that part? http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#multiple-binary > >> This is not the first step to be taken. Before that, make all brlcad tools >> properly >> work on /usr instead /usr/brlcad, and use system shared libraries. > > Okay. > >>> 3. in script postinst I drive ld.so.conf as the final step: > ... >>> 5. I added file "/etc/ld.so.conf.d/brlcad.conf" with contents like: > ... >> About point 3 and 5, I'm not sure that is good to share system wide >> the /usr/brlcad/lib shared libraries. This will raise more problems than >> solutions I think. > > So how do you handle the user finding brlcad libs? LD_LIBRARY_PATH is > not good practice as I understand it these days--I thought using > ld.so.conf.d was the thing to do. > First of all, let me tell you that I'm not a programmer, I'm just a Linux advanced user, so my knowledge is very limited. Until I know, brlcad commands includes in theirs executable the path to the brlcad shared libraries, and so, they not need any external reference to find them. I've not deeply test but last deb package built from trunk, run brlcad commands without problems, and there aren't any external reference to the brlcad shared libraries. In the other hand, if we install some library in /usr/brlcad/lib and the same library is installed in the standard system lib path but with a different interface and we share system wide the brlcad shared libraries, this can make to any program using this library to fail if it finds first the wrong one. Sure this can be improved and it can be done in the Debian fork too by using the system shared libraries. -- Jordi Sayol ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
