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
After some discussion on #fink, I want to modify my message about the shared
libraries policy a bit. Here's the revised version. If you have any
further comments, please discuss them here quite soon, as I plan to add a
statement like this to the documentation in a few days. Also, everyone
shoul
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 requ
How hard would it be to implement something like this:
Type: Multi
Packages: %n-docs (= %v-%r), %n-bin (= %v-%r), %n-shlib(= %v-%r), etc
Package-script: %n-%v-%r.info
#this is a master sh(?) script, which makes all the debs in Packages
before removing the directory/going on
etc...
sorry, I have
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 separat
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, w
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 thin
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 %i/lib/li
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
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 install
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 t
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 new foo...
But there are files which conflict between
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 /sw/s
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 g
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 built, anyway, so there
is no point in have it BuildDepend
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 contai
16 matches
Mail list logo
