David Ayers wrote:
gnustep-dl2-nox(-dev)
EOControl/EOAccess
That's OK, but the runtime library package name should embed the
soname, e.g. gnustep-dl2-nox-0. Furthermore, we'll get 2 lintian
warnings `package-name-doesnt-match-soname' while if it is libeoaccess
there would be only one (for
On Fri, Jan 8, 2010 at 5:07 AM, Yavor Doganov ya...@gnu.org wrote:
gnustep-dl2 [1]
DBModeler
GDL2 palette
eoutil, gdlgsdoc
EOModeler (as private library)
Recommends: libeointerface-dev (which will pull in libeoaccess-dev)
Sorry It just hit me that both DBModeler and GDL2 palette use
Matt Rice wrote:
Sorry It just hit me that both DBModeler and GDL2 palette use the
EOModeler library which might pose a problem for making EOModeler
'private'
That's not a problem at all -- both will link against EOModeler with
RPATH, which will be shipped in the same binary package.
On Mon, Jan 4, 2010 at 5:31 AM, Yavor Doganov ya...@gnu.org wrote:
Matt Rice wrote:
Yavor mentions that (although they're intended to be public
libraries, nothing in GNUstep uses them)
Oh, that was misleading. What I meant is that no package in Debian
currently uses gnustep-dl2 (its
Matt Rice wrote:
Likewise, this should be libeointerface0/libeointerface-dev. But
you didn't mention EOModeler. Is its place here, too?
Ahh, yeah I forgot about that library, no EOModeler can go in its own
libeomodeler
But the goal is to decrease the number of the binary packages as
On Thu, Jan 7, 2010 at 1:12 PM, Yavor Doganov ya...@gnu.org wrote:
Matt Rice wrote:
Likewise, this should be libeointerface0/libeointerface-dev. But
you didn't mention EOModeler. Is its place here, too?
Ahh, yeah I forgot about that library, no EOModeler can go in its own
libeomodeler
Hello everyone,
IMHO the packaging for GDL2 could take into account the non-gui/gui
scenarios and would look something like this:
gnustep-dl2-nox(-dev)
EOControl/EOAccess
gnustep-dl2-gui(-dev) (depends on dl2-nox)
EOInterface
gnustep-dl2-tools(-dev) (depends on dl2-nox)
EOPalette
On Mon, Jan 4, 2010 at 1:37 AM, Federico Gimenez Nieto fgime...@coit.es wrote:
El 03/01/2010 21:26, Matt Rice escribió:
[.]
I'm not sure if it would be against debian policy to ship the Gorm
bundle with DBModeler.app that is another option if possible since the
gorm bundle is like a
Matt Rice wrote:
Yavor mentions that (although they're intended to be public
libraries, nothing in GNUstep uses them)
Oh, that was misleading. What I meant is that no package in Debian
currently uses gnustep-dl2 (its libraries or whatever).
but DBModeler isn't really a standalone
Federico Giménez Nieto wrote:
2010/1/4 Matt Rice ratm...@gmail.com:
Ahh, sorry I meant the 'package GDL2Palette bundle with DBModeler',
adding a dependency on the existing Gorm.app package to it,
Yes, in my opinion it should be enough to add a dependency on gorm.app
to the new
El 03/01/2010 21:26, Matt Rice escribió:
[.]
I'm not sure if it would be against debian policy to ship the Gorm
bundle with DBModeler.app that is another option if possible since the
gorm bundle is like a plugin for Gorm which DBModeler communicates
with, its not entirely necessary, but is
2010/1/4 Matt Rice ratm...@gmail.com:
AFAIK, since gorm.app is already part of debian, that package should be
used instead of including convenience copies of code, see [1] for
details. On fact, the current gnustep-dl2 package depends on gorm.app
for its build and installation. But right now
(Typo fixes to avoid possible confusion; sorry.)
Явор Доганов wrote:
Every shared library (in /lib and /usr/lib) should be packaged as
libfooN and libfoo-dev (in rare cases libfoo2-dev).
s/libfoo2-dev/libfooN-dev/
that use the library to depend on libfoo-dev and to automatically
Hi all,
I'm in the process to adopt gnustep-dl2 debian package, [1]. You can
check the progress so far at [2]. In order to comply with Debian
Policy, Yavor Doganov (Cc'ed) suggested that the libraries in the
package (libEO*) should be packaged separately from dbmodeler.app
([3], [4]). As Yavor
2010/1/3 Federico Giménez Nieto fgime...@coit.es:
Hi all,
I'm in the process to adopt gnustep-dl2 debian package, [1]. You can
check the progress so far at [2]. In order to comply with Debian
Policy, Yavor Doganov (Cc'ed) suggested that the libraries in the
package (libEO*) should be
15 matches
Mail list logo
