Bug#644943: Please switch source package to OCE

Adam C Powell IV hazelsct at debian.org
Tue Nov 1 13:07:52 UTC 2011


Hello Denis et al.,

Apologies for the delay and for generally being out-of-pocket recently.

On Thu, 2011-10-27 at 09:56 +0200, D. Barbier wrote: 
> On 2011/10/13 Sylvestre Ledru wrote:
> > Le jeudi 13 octobre 2011 à 10:08 +0200, D. Barbier a écrit :
> >> On 2011/10/11 Adam C Powell IV wrote:
> >> > Dear Denis,
> >> >
> >> > Denis (and others on the CC list), what do you think?  Can we keep the
> >> > same source package name, unless/until OCE diverges away from the main
> >> > OCCT?
> >>
> >> I have mixed feelings about package names.  OCE developers decided to
> >> not use OCC or OpenCascade names in order to make it clear that this
> >> product is not endorsed by OpenCascade SAS.  On the other hand, it is
> >> of course much more convenient to keep the same names.  My preference
> >> goes to s/opencascade/oce/ in source and binary package names though.
> > Idem. Different teams, "different" projects => different names...
> 
> Hello,
> 
> I just pushed a db/debian branch into upstream repository
>   https://github.com/tpaviot/oce/tree/db/debian
> It will not be merged into our trunk, I pushed it there since I did
> not know where to publish it.
> It has been minimally tested, but needs more polishing.

Great!  I like that you've continued with the old OCC changelog.

But I think it makes sense to do development of the package on the
"official" Debian git server, to facilitate team management.  In general
when upstream creates a debian/ directory, it confuses things because
there can be multiple "Debian packages" floating around.

> So, how do we proceed now?  Do we change package names, as in this
> branch?  If yes, do we switch to a new repository?

That's a good question.  I could go either way:
     1. tart a brand new repository, since it's a new package with new
        names -- but then start with a new changelog; or
     2. Use the oce tarball as a new "upstream" on a renamed or cloned
        repository, or a branch, to more clearly show the changes
        between OCC and OCE.

I think #1 makes more sense, particularly because it's perfectly easy
for someone to "diff -ur" the two trees and see the changes, and we
aren't trying to track patch-by-patch changes -- that's OCE upstream's
job.  We can leave opencascade.git in place, and start a new oce.git in
the same place.

Also, Denis, I think Conflicts is better than Breaks because apt will be
sure to remove a Conflicts package before trying to install the new
package; and it would be good to indicate Provides as well to smooth the
transition.

When OCE enters unstable, we file important (future FTBFS) bugs against
OCC's rdeps.  Then when OCE enters testing, ask the ftp-masters to
remove OCC from unstable and testing and turn the unclosed important
bugs to serious ones.

Sounds good?

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20111101/45135fa6/attachment.pgp>


More information about the debian-science-maintainers mailing list