Bug#457075: Question on Salome package organization
On Tue, 2010-04-27 at 13:58 -0400, Adam C Powell IV wrote: > On Tue, 2010-04-27 at 09:36 +0200, Nicolas Chauvat wrote: > > > One more argument: we could plug Aster into Salome thanks to pylotage. > > > > > > If we are lucky, it could even make it for Squeeze! > > > > +1, let's try to get it into squeeze. It will mean more users and > > developers, even though the packaging changes completely for squeeze+1. > > Done! Sorry, bunch of errors on my part, should have -7 on lyre and uploaded by the end of today. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Question on Salome package organization
On Tue, 2010-04-27 at 09:36 +0200, Nicolas Chauvat wrote: > On Mon, Apr 26, 2010 at 11:07:18PM +0200, Sylvestre Ledru wrote: > > Well done for this packaging! > > Yep, nice job. Thanks. > > One more argument: we could plug Aster into Salome thanks to pylotage. > > > > If we are lucky, it could even make it for Squeeze! > > +1, let's try to get it into squeeze. It will mean more users and > developers, even though the packaging changes completely for squeeze+1. Done! -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#457075: Question on Salome package organization
On Mon, Apr 26, 2010 at 11:07:18PM +0200, Sylvestre Ledru wrote: > Well done for this packaging! Yep, nice job. > One more argument: we could plug Aster into Salome thanks to pylotage. > > If we are lucky, it could even make it for Squeeze! +1, let's try to get it into squeeze. It will mean more users and developers, even though the packaging changes completely for squeeze+1. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100427073631.ga4...@volans.logilab.fr
Bug#457075: Question on Salome package organization
On 26 April 2010 22:07, Sylvestre Ledru wrote: > Le lundi 26 avril 2010 à 13:18 -0400, Adam C Powell IV a écrit : >> In short, I think this package is about where OpenCASCADE and OpenOffice >> were when first uploaded: crude and simple packaging of a very useful >> piece of software, with plans for big packaging changes. I'd like to go >> ahead and upload in about 24 hours unless anyone has a strong objection. > Well done for this packaging! > I say, the sooner, the better! > > One more argument: we could plug Aster into Salome thanks to pylotage. > > If we are lucky, it could even make it for Squeeze! > > Sylvestre > Upload! =) we do have mingw packages in the archive which are not in the perfect condition but they are extremly useful. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/h2v86ecb3c71004261627te0777e3ck988340b3b28...@mail.gmail.com
Bug#457075: Question on Salome package organization
Le lundi 26 avril 2010 à 13:18 -0400, Adam C Powell IV a écrit : > Greetings again, > > salome 5.1.3-6 is up at http://lyre.mit.edu/~powell/salome/ . The > package is big and ugly and kludgey, but I've tested it a bit and > confirmed that it runs from the menu. > > I built it with -sa and closed the ITP bug in the changelog, so it > should be ready for its first upload. The question is: should I upload > it? > > Here are the arguments as I see them. For uploading: > * It seems to work (run), and thus can meet users' needs > * Quicker reply from ftp-masters on copyright and other uploading > issues > * Broader testing, especially if it gets into squeeze > * Possibly more devs interested in helping with debugging and > package development > * Use of the BTS to track issues > * It will take a lot of work to fix some of the issues below, > let's work on them together > > Against uploading: > * The package is buggy! In particular, module loading > requires .so files, so one needs to install about 100 MiB worth > of -dev packages in order to run it > * Package layout is not finalized, as demonstrated below > * Shared library versioning isn't even finalized... > > In short, I think this package is about where OpenCASCADE and OpenOffice > were when first uploaded: crude and simple packaging of a very useful > piece of software, with plans for big packaging changes. I'd like to go > ahead and upload in about 24 hours unless anyone has a strong objection. Well done for this packaging! I say, the sooner, the better! One more argument: we could plug Aster into Salome thanks to pylotage. If we are lucky, it could even make it for Squeeze! Sylvestre -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272316038.1767.28.ca...@zlarin
Bug#457075: Question on Salome package organization
Greetings again, salome 5.1.3-6 is up at http://lyre.mit.edu/~powell/salome/ . The package is big and ugly and kludgey, but I've tested it a bit and confirmed that it runs from the menu. I built it with -sa and closed the ITP bug in the changelog, so it should be ready for its first upload. The question is: should I upload it? Here are the arguments as I see them. For uploading: * It seems to work (run), and thus can meet users' needs * Quicker reply from ftp-masters on copyright and other uploading issues * Broader testing, especially if it gets into squeeze * Possibly more devs interested in helping with debugging and package development * Use of the BTS to track issues * It will take a lot of work to fix some of the issues below, let's work on them together Against uploading: * The package is buggy! In particular, module loading requires .so files, so one needs to install about 100 MiB worth of -dev packages in order to run it * Package layout is not finalized, as demonstrated below * Shared library versioning isn't even finalized... In short, I think this package is about where OpenCASCADE and OpenOffice were when first uploaded: crude and simple packaging of a very useful piece of software, with plans for big packaging changes. I'd like to go ahead and upload in about 24 hours unless anyone has a strong objection. -Adam On Thu, 2010-04-22 at 19:23 -0400, Adam C Powell IV wrote: > Hello André and list, > > On Thu, 2010-04-22 at 15:04 +0200, Andre Espaze wrote: > > Dear list, > > > > Now that salome-5.1.3-5 is running, I started a documentation on its > > content and finally found a question on Debian package organization. > ... > > The current package organization is a "legacy" system from back when I > first started to package version 3.2.6. It's really not very good. :-) > > > I am aware of my ignorance on Debian package policy, > > Debian package policy doesn't require any particular organization, it > just indicates what should be in shared lib, python, etc. packages. > > > but I would suggest > > such kind of organization: > > > > - salome-core (the usual pre and post processings) > > - salome-core-dev (its development files) > > - salome-advance (the advanced uses) > > - salome-advance-dev (its development files) > > - salome-dev (every module for the Salome developer with > > development files) > > - salome-doc (the actual documentation) > > I like this organization. It's something like the transition we did for > Open CASCADE a couple of years ago, led by Jason Kraftcheck and Denis > Barbier. [1] > > [1] http://lists.debian.org/debian-science/2008/01/msg00013.html > > I have a few suggestions: > * There are a lot of "[T|t]est*" binaries in the salome package. > It would be good to separate these out into salome-core-test > etc. packages so one doesn't need to install them along with the > main binaries. > * The shared libraries should go in their own packages, such as > libsalome-core etc. Because their interface changes with every > version, they should probably change from the 0.0.0 version > designation to using the libtool "-release" flag with the > package version, e.g. libGLViewer-5.1.3.so . > * I think there should be a package called plain "salome" with the > core functionality which people expect to have when they think > of Salomé. > * The documentation also desparately needs to break up! I suggest > salome-doc for the non-built docs, and salome-user-doc and > salome-dev-doc for the docs made with "make -C [MODULE]/doc > usr_docs" and dev_docs respectively. > * As for implementation, instead of SALOME_MODULES, perhaps we can > have SALOME_CORE_MODULES, etc., and install them with DESTDIR= > $(CURDIR)/debian/salome-core or -advanced etc., and then move > around the shared libs, header files, symlinks, and python files > from there. > > > Another solution would be to provide a package for every Salome module > > but it seems to be confusing because of the modules number. Moreover the > > package creations is going to become inconvenient while producing very > > little improvement to the user. Who is going to create a mesh without > > using the GUI but only through a CORBA service (thus installing only > > salome-kernel and salome-smesh)? The same scenario can be repeated to > > others modules as well. > > I agree this would not be a helpful solution. > > > In conclusion, is it worth to wonder about a new Salome package > > organization? > > Definitely! Thanks for the suggestion. It will all take a lot of work, > and should probably happen after the initial package goes into unstable, > but it will make people's lives much easier in the post-squeeze release. > > -Adam --
