Re: Splitting up OpenCascade packages
On Mon, 2008-01-14 at 09:31 -0600, Jason Kraftcheck wrote:
> Adam C Powell IV wrote:
>
> Thanks for for considering splitting up the packages (and for packaging
> OpenCascade). I will read the archive of the debian-science discussion
> when I get a chance, but I haven't done so yet. Hopefully the majority of
> my response below isn't stuff that's already been worked out in other
> discussions.
Nope, mine was really the only comment on the substance of your post.
(There was also a thank-you from Sylvestre.) So you're all caught-up.
I'm bringing this back to -science with copies to you and Tim Tautges.
> >> I have a couple of reactions:
> >>
> >> -common is a name generally used for architecture-independent deps, e.g.
> >> openmpi-common has a bunch of data files in /usr/share, so I'd use
> >> -kernel or -base or something similar.
> >>
>
> I think that if you want to call it 'kernel', then you should move the
> TKMath toolkit from -core to -kernel so that it corresponds to the
> 'kernel' component described in the documentation. Otherwise it might be
> better to call it 'base'.
>
> I had put TKMath in -core because it made more sense when considering
> library dependencies (WOK doesn't require it.) I'm not sure if that was
> the best choice. Perhaps it would be better to try to follow the
> documented OpenCascade modules in this case?
Sounds like a sensible default.
> >> You're using ldd to generate these dependencies. But several of the
> >> libraries are over-linked, that is linked to libraries where they don't
> >> call any symbols, hence the thousand-odd warnings generated by
> >> dh_shlibdeps at the end of the build. I wonder if the graphs are
> >> simpler, and have fewer X links, than you make them out to.
>
> It will be interesting to see how things change if you get a chance to
> address the over-linking issues. There are a lot of dependencies that are
> not shown in the graph. The graph only shows the least-direct dependency
> path (e.g. if A->B, A->C, and B->C, then A->C is not shown.) So it is
> possible that the graph would be quite similar even if the over-linking
> were fixed (or does dh_shlibdeps already take that kind of thing into
> account?). As for the X dependencies, TKService depends on X and
> everything that is shown as depending on X (except TKDraw and the WOK
> stuff) also depends directly or indirectly on TKService.
Makes sense. I don't think I'll have time for such a labor-intensive
task for a while, as Salomé packaging is proving to be a full-time job
(easily 40 hours thus far). You're probably right that things wouldn't
change a lot, and if they do, we can use your scripts to adjust as
appropriate.
> >> Splitting up the libs should be no problem. Splitting up the headers
> >> among the -dev packages will be a herculean task! There are some
> >> fifteen thousand of them, including nearly four thousand beginning with
> >> the word "Handle"!! Are you volunteering? :-)
> >> dpkg -c libopencascade6.2-dev_6.2.0-6_amd64.deb | grep include | wc
>
> I wouldn't have suggested splitting up the packages if I didn't think
> there was a practical solution to this, particularly with regards to
> maintaining it for future releases. The list of packages and other source
> directories in pkgsrc.txt and the 'occfiles' script are sufficient to
> generate the header list. For example, try something like "occfiles
> /opt/OpenCascade6.2 TKernel TKjcas OS | grep ^headers:".
>
> The occfiles script will error out if it cannot assign every header in
> inc/ to some source package. So as long as the list of toolkits and
> source directories assigned to packages (pkgsrc.txt) contains everything
> in the output of the 'toolkits' script you should be guaranteed that every
> header is being assigned to some package (hopefully the correct one...)
Terrific!
> The occfiles script still needs some additional work to handle data files.
> Also, it only works on the toolkit/directory level so there's some
> sloppiness in assigning 'OS' to the base package. That directory appears
> to contain .tcl files for several packages.
Understandable. But not a show-stopper -- it would be only a minor bug
to include those in -base (or -kernel or whatever).
Thanks again,
-Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
Reply to: