[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> >> 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...)


> 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,
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools

Reply to: