I would like to thank all of you for your assistance in implementing the
most recent phase of the shared libraries project. By now, virtually
all packages which contain .dylib's also have the Shlibs: field which
declares those .dylib's, and virtually all of the Shlibs fields use the
revised
Over the last few days, the following shared-library versions have been
added to the unstable tree. The ones with a star will be moved to stable
later this week, after some time has passed for testing.
-- Dave
*crypto/gnome-vfs-ssl-1.0.3-5.info
crypto/gnome-vfs-ssl-1.0.5-3.info
Sounds like a good plan, David. Now, can you start conversion on
those packages that already are split into a base and -shlibs package
but don't use SplitOff for that yet? Like gdk-pixbuf. For it would
reduce the build time...
Max
--
---
Max Horn
A section on shared libraries has now been added to the fink packaging
documentation, under policy. It is based on the email I circulated
a few weeks ago, with some improvements as suggested by others. I will
be happy to incorporate any other suggestions for improvement.
-- Dave
Hi Peter. I agree that ultimately we need the ability to generate more
than two debs from the same package file. (This is actually a bit different
from the other issue that has been discussed from time to time, namely
several variants of a package (like x/no-x) which would each require
a
OK, folks, let me set some things straight once more:
1) No, this change is not made easier if we move at the same time to
a new package format. I tried to explain it several times in the
past: any new package format would almost entierly be transparent to
the backend of fink, and only
I would like to make a suggestion:
Since this is going to add complexity to the fink code (a lot of
complexity, I might add :-) and we might choose this moment to upgrade
the .info format. This will need additional discussion, but I believe
we have a mostly workable xml format decided (check
I have one small problem with your proposal, it only lets us
make 2 debs from one build.
I am going to put my proposal in an example:
Package: mystuff
Version: 1.2.3
Revision: 1
Source: http://www.example.com/mystuff.tar.gz
Debs: shlibs, docs, bin
DebShlibs: %i/lib/libmylib-1.2.3.dylib
At this point, it'd be cleaner to do something like the debian/control
file, where the subpackage-specific pieces broken into separate chunks,
separated by a blank line, each headed with its own Package: field.
Munging this information into the names of the fields themselves is
not a pretty
Fair enough, I don't really care how it is set up in the info
file, I just think that limiting the system to 2 debs is
inappropriate.
Peter
On Thursday, February 14, 2002, at 01:04 PM, El JoPe Magnifico wrote:
At this point, it'd be cleaner to do something like the debian/control
file,
Hi again Max.
I was looking more closely at a shared library example in Debian, and it
appears that they use a similar trick to what you've just done with zlib:
they divide the files between the packages like this:
Package foo contains:
/sw/lib/foo.N.x.y.dylib
/sw/lib/foo.N.dylib -
At 17:11 Uhr -0500 02.02.2002, David R. Morrison wrote:
Hi again Max.
I was looking more closely at a shared library example in Debian, and it
appears that they use a similar trick to what you've just done with zlib:
they divide the files between the packages like this:
Package foo contains:
At 18:11 Uhr -0500 02.02.2002, David R. Morrison wrote:
H... I'm confused about the dependency relationships between foo-shlibs
and foo (using your terminology, Max).
Do we say that foo depends on foo-shlibs? I guess that is OK; foo-shlibs
is going to have to load the entire source to get
Max Horn [EMAIL PROTECTED] wrote:
At 18:11 Uhr -0500 02.02.2002, David R. Morrison wrote:
[snip]
There is one other issue: sometimes, there are a bunch of auxiliary
files which belong to a particular version of the library, and which
could get stored in /sw/lib/foo/N/ or in
At 18:29 Uhr -0500 02.02.2002, David R. Morrison wrote:
Max Horn [EMAIL PROTECTED] wrote:
[...]
The WHOOPS above is this: the value of %n is foo, not foo-shlibs. So I
think that we are creating %i/share/doc/%n not %i/share/doc/%n-shlibs.
Either that, or we have to duplicate the
At 18:41 Uhr -0500 02.02.2002, David R. Morrison wrote:
Another crucial thing, to get the upgrade to work:
foo-shlibs version a.b-c has to Replace: foo ( a.b-c).
The reason for this is, if you have the OLD foo package installed, dpkg
is going to try to install foo-shlibs before installing the
16 matches
Mail list logo
