Do the doc and bin packages need DocFiles?
Every package needs DocFiles (or a less-automated installation of something
into %p/share/doc/%n).
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
Mat Caughron [EMAIL PROTECTED] wrote:
[snip]
Quite frankly, I'm ready to give up on Apple's pkg stuff. The only thing
it has to offer at this point is a GUI installation method, which, from
reading the mailing lists, it looks like the fink will have at some point
in the not-too-distant
Bill Bumgarner [EMAIL PROTECTED] wrote:
I saw a conversation go by that mentioned the possibility of using an
alternative to dpkg for package management...
I have no particular preference but thought I would toss out that Apple is
moving more and more to using RPM internally and that the
Max, con you explain this little item in your patchfile for the new
libxml2 from today? You've patched Makefile.in with
-LDFLAGS = @LDFLAGS@
+LDFLAGS = -L./.libs @LDFLAGS@
and I'm curious about what this does and why it's necessary. (And if
the same effect could be achieved with SetLDFLAGS .)
At the very least, you could create all 15 .info files, wrap them up into
a single .tar file, and put the .tar file onto the package submission
tracker. Don't make me download 15 separate things!
Thanks,
Dave
___
Fink-devel mailing list
[EMAIL
If Martin's observation is correct, a concern arises: How was the binary
being distributed by xfree86.org compiled, and is it still equivalent
to fink's, for the purposes of installing other fink packages?
-- Dave
___
Fink-devel mailing list
[EMAIL
Thanks, Max, for doing all of this package validation stuff.
I have one question though. For packages of type nosource or bundle,
do we really want a license field? If so, what should the rules be
about that license field? Since we are not really redistributing anything
with those packages, I
Could I suggest adding fink check and/or fink validate to the list
of commands that one sees when running fink --help? (Or else to the
man page... or both!) That will help us remember where to find this
later.
Thanks,
Dave
Max Horn [EMAIL PROTECTED] wrote:
Sorry, should have mentioned
Max Horn [EMAIL PROTECTED] wrote:
OK, it now doesn't warn for bundle package. it still warns for
nosource packages, though - the difference between those essentially
is that bundle works as an umbrella for other packages, hence
doesn't need a license field. But nosource means a
Martin Costabel [EMAIL PROTECTED] wrote:
A little problem with the new geomview: It didn't upgrade gracefully.
/sw/bin/geomview used to be a directory, and it remained so after the
upgrade. It should now be a symlink to the geomview executable script,
so there was no geomview executable. I
Hi. If you look on the package submssion tracker you will see that
someone was working on Amaya 5.2 a few months ago; you might be able to
take advantage of the previous efforts. That tracker is also the way
to submit a new package for consideration. It is linked from fink's home
page.
The
Alexander Strange has submitted a revised version of the gimp package to
the tracker, taking over as maintainer from chrisp. (Thanks!)
There is one issue with this package that I wanted to bring up. It has
a linker flag -lcrypto and so will either use /usr/lib/libcrypto.dylib
or
I'll take over as the new libpng maintainer (from chrisp). I made a fink
package for the latest upstream version. However, I have not put it on
CVS, because the major version number has changed and if you install the
new one, you will break around a dozen other packages which depend on it
I have one more minor adjustment to suggest for the fink validate command:
when checking whether the package name is included in the Description,
the check should be case-insensitive. I've just encountered a package
in the tracker whose description begins with a capitalized version of
the
Thanks for the explanation, Max. It's something that I kinda knew, but
had forgotten.
I haven't ever used Debian/Linux, but what I am hoping will happen after
we get this going is this: if I install a new version of a library,
dpkg will automatically recompile all of the guys that depend on
I've been studying the Debian policy about shared libraries, and I think
I understand their strategy much better now.
It has several components. First, the libraries themselves are separated
from the headers -- you have to have two packages per program. (Well,
actually three in many cases,
Hi Max. I'm testing your new zlib, and it works great. In both of the
packages I depended which depend on zlib, at the outset, otool -L gave
/sw/lib/libz.1.dylib (compat. 1.1.3, current 1.1.3)
Then I installed the new zlib and everything still ran.
Then I recompiled my packages; now otill
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 -
Two more comments about the new zlib
1) I have only a vague recollection about the earlier discussion of this.
Was zlib originally absent from darwin/OS X, and added in a later revision?
If so, do you need some kind of darwin-version test for the new package?
2) Since Apple is providing libz.h,
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/share/foo
Max Horn [EMAIL PROTECTED] wrote:
Gnumeric crashes for me upong launch. never has been different. But
now also gabber crashes for me when I try to login. Looking at my
stack trace, both crash inside some gtkmm/gnomemm function... I
wonder if there is something deeper going on there...
Great! I think I can finally put gnumeric back into stable, then.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
One correction to the earlier proposal. In the section on upgrading, I
should have said:
If shared libraries (or any other files now present
in foo-shlibs) were installed previously, then these new packages should
say
Replaces: foo ( earliest. compliant.version)
so that
Max, along these lines, I noticed that freetype2 is included in xfree86-4.2.
Like in the case of zlib, there is a version mismatch between fink's
version and xfree86's version, so we can't simply drop the fink freetype2.
/usr/X11R6/lib/libfreetype.6.dylib (compatibility version 6.0.0,
El JoPe Magnifico [EMAIL PROTECTED] wrote:
Cool. My gtk+ was apparently already linked against the right version,
but my gnome-libs and gdk-pixbuf were not, so I updated just those
and gnumeric works a-okay for me now too. Thanks!
Any ideas on a clean way to automate this kind of
A small footnote on this: There has been a proposed openldap-ssl package
sitting in the package submission tracker for a couple of weeks, if that
makes someone's work easier.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
Hi. The most minimal form of implementing shlibs just divides the package
in half, with pkg-shlibs containing libpkg.N.x.y.dylib, libpkg.N.dylib
and often nothing else. (In particular, libpkg.dylib belongs in pkg,
not pkk-shlibs.) It is OK to put /sw/share/pkg/N/* in there as well,
so long as
I agree that in many cases we should have three packages from pkg, and other
packages would say (using the current names):
Depends: pkg-shlibs, pkg-bin
BuildDepends: pkg
Also, pkg depends on pkg-shlibs (and maybe should also depend on pkg-bin
in some cases).
Right now, the other packages
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
There is another aspect of this which has not yet been mentioned.
When fink is analyzing dependencies, it (apparently, since I can't read
perl) creates a list of existing .info files which it can suggest it
will build in order to meet unmet dependencies. These will have to be
generated in some
Two more comments for now:
1) InfoDocs also needs to be on the allowed list, since we can't control
where the .info files will be installed. Similarly, UpdatePod.
2) Although it would be great in principle to somehow have every package
with a %n-shlibs splitoff to have a default Depends:
Notice that the license files for package foo go in
/sw/share/doc/foo/
So if we have foo, foo-bin, and foo-shlibs, the license files will go in
/sw/share/doc/foo
/sw/share/doc/foo-bin
/sw/share/doc/foo-shlibs
The developer will have the option of using the DocFiles line for any of
the
I'm looking for a volunteer to check out the Nautilus package on the
package submission tracker.
I can't check this one myself, because it depends on mozilla and I am one
of the people for whom mozilla does not compile correctly.
Nevertheless, this package might be useful for people who have
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
Kyle Moffett [EMAIL PROTECTED] wrote:
On Sunday, February 24, 2002, at 07:25 , Jeff Whitaker wrote:
the .so for A::R and A::C both statically link to libapreq, which
should internally bind the entry points between the A::R/A::C and
libapreq libs, and it does on every platform including
I have separate binaries for /bin/sh and /bin/zsh, although they are
identical in size (449616) and date (Dec 31). Presumably they were
installed by the 10.1.3 upgrade. I don't know how to check the version
number of sh or zsh, which Matthias said was 3.0.8 in his case.
-- Dave
I enclose a suggested addition to the shared libraries documentation.
I believe that it addresses the problems Martin has uncovered. Any
comments?
-- Dave
Packages containing both binary files and libraries
When an upstream package contains both binary files and libraries, some
care must
fink describe lyx and fink describe xdvi will reveal the email addresses
of the maintainers.
The download URL for xdvi was fixed quite some time ago. You need to update
using fink selfupdate-cvs and then the corrected xdvi-22.48-1.info file
will be used.
-- Dave
Kyle, the big difference between my proposal and your proposal is that
my proposal puts the burden of keeping things straight on the maintainer
of the package providing the libraries, and your proposal puts the
burden of keeping things straight on the maintainers of other packages.
Under your
Under your system, let's say I introduce foo-3.0.0 which is not
backwards
compatible. Now all of the other developers need to revise their
packages
immediately, because their packages were saying
Depends: foo (= 2.0.0)
but now they need to say
Depends: foo (= 2.0.0 3.0.0)
I thought it might be worth sketching a possible roadmap to full shared
libraries support for fink.
Phase 1: Convert some of the shared libraries packages to the
foo/foo-shlibs system. Be sure to include all packages where the major
version number is likely to change soon, or has
I've just updated the system-tetex package, which I try to do very
infrequently. One of the new features is a much more robust
pre-install script.
I haven't been able to find a solution to the following problem: some
users will need to do a bit of disk housekeeping (removing obsolete
files by
Hi Masanori.
Before yesterday, I was using the October Developer Tools, and I was unable
to build a working mozilla.
Now I have installed the December 2001 Developer Tools, and I rebuilt mozilla.
Everything works! So I think you have found the solution to the problem.
I know that somebody
I have written a system-ghostscript package, but I am undecided about
whether it should be included in fink or not.
As some of you know, there is a widely-used teTeX distribution (which
accompanies the program TeXShop), and we support this as an alternative
with fink's system-tetex package. The
I think I can explain what is happening during the post-installation. One
of the binaries which was compiled during the building of the package is
executed, which is supposed to configure mozilla. However, it crashes,
so the post-install script fails (with a not very informative message).
If
Jeff Whitaker [EMAIL PROTECTED] wrote:
And BTW: this comes from the hdf5 dependency. hdf5 depends on hdf, which
depends on f2c fortran. If people really don't like that, I can remove
the hdf5 dependency from imagemagick. Who really uses hdf to store images
anyway?
Maybe this is a good
Hmmm... the latest darwin-dev has a relevant post:
Subject: apache_mod_php module in cvs
From: Marko Karppinen [EMAIL PROTECTED]
To: darwin-development [EMAIL PROTECTED]
PHP 4.2.0 is due to be released on March 22nd, ie. in two weeks. This will
be the first PHP version with official Mac
From [EMAIL PROTECTED] Sat Mar 9 15:48:27 2002
At 19:31 Uhr +0100 09.03.2002, Max Horn wrote:
OK, so I am working on PHP 4.1.2. Problem is, it tries to use gd,
but gd is only available as a static library. Yeah, I read the
comment, it is compiled with -fno-common, but libtool still
I discovered in the last few weeks that for one of my packages (latex2html)
the upstream source changes from time to time without the name of the
sourcefile changing. I've discussed this with the upstream maintainers
but they won't be changing their operating methods. So here's what I've done
Has anybody ever seen this behavior before? I have a file. I put it in
my checked out copy of the source. I say cvs add foo; cvs commit and
the file gets corrupted, both on my copy and at the CVS site.
I don't notice this until somebody points it out, then I'm not sure if
I'm the one who
Justin, if you do fink install fink-0.9.8 you should get back to
pre-splitoff.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
We've had a package called fvwm-common since last July or August, which
both fvwm and fvwm2 depend on. It works in exactly the same way -- all
of the overlapping files go there. I borrowed the naming from debian
at the time. I think we can stick with that naming convention.
-- Dave
I can verify that php-4.1.2-1 will not build if the old version of gd is
installed rather than the new version. I recommend updating it to say
BuildDepends: gd (= 1.8.4-6)
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
The thing to keep in mind is that the package which contains headers might
get removed by users, and nothing else can depend on it. So any binary
which will only be used at compile time by other packages is fine for the
main package; anything which might be used at runtime by other packages
(or
I'd like to remind all core fink developers of the most important rule when
committing things to CVS:
IF YOU HAVE MADE ANY CHANGE TO YOUR PACKAGE, YOU MUST INCREASE THE
REVISION NUMBER.
Like any good rule, there are exceptions to this: you can modify the
Description field, for example, or
I have another small proposal to make related to the long-term shared libraries
project: I suggest that we add a new boolean field BuildDependsOnly. If
it is true, the package it is in would not be allowed to be Depended on
by any other package, only BuildDepends would be allowed. Fink won't
Justin Hallett [EMAIL PROTECTED] wrote:
hmmm I can't see why not but instead of adding more to the build time run
add it to the fink check command, which I hope all fauthors are using
right?:P
Actually, we can worry about the implementation later. We won't want to
implement this until the
Benjamin Reed [EMAIL PROTECTED] wrote:
Another thing that occurred to me while packaging is, is there a way to
do multilines inside a splitoff? While making the kdelibs package, I have
a huge line of files in the Files: section of the bin and shlibs
sub-packages. Can those be continued
Jeremy Higgs [EMAIL PROTECTED] wrote:
Hi David,
Just to clarify things... A couple of minutes ago, I updated the download
URL for qcad (in unstable), due to a report from a user that the previous
URL no longer worked. I assume this is OK, as no recompilation of the
package is necessary?
Jeremy Higgs wrote:
Just out of interest, Max, what's the easiest way to use the split-off
packages when using 'fink selfupdate-cvs'? As far as I know, the split-offs
module is not checked out when using this, so should someone wishing to try
out the split-off packages check the module out
If I understand correctly what the dpkg shlibs stuff will eventually do
for us, at some point in the future each fink package which provides
shared libraries will need to give some data about those libraries to
be used by the dpkg-shlibs system.
Max, will we put this directly in the .info file,
Max Horn [EMAIL PROTECTED] wrote:
The reason for bringing this up now is it would be good to start encouraging
people to provide this information in their packages, pretty soon. To
avoid fink validate problems, we might want to add one more field (Shlibs)
to the list of known fields right
My point of view about the dependent packages is this: if a user tells us
that he/she is successfully using the latest version of package foo, then
we know that he/she is also successfully using at least some version of
everything that foo depends on (even if the user doesn't point that out
I have now committed a second draft of revised documentation for fink to
CVS. Again, only the file web/xml/packaging/packaging.xml was committed,
which could be processed into php/html if you like.
Today's changes:
1) minor edits to yesterday's changes
2) divided the list of allowed fields
Sending a message about it here was a good way. I have just added it to
stable.
Another possible way is to re-open the package submission tracker item
which you originally used to submit the package, and make the request
there.
-- Dave
___
Hi all.
I've noticed that several of our essential packages build shared
libraries (for example, bzip2 and ncurses). This presents a bit of a
quandry for the shared libraries policy.
If we impose the shared libraries policy on these packages, they'll be
split into main and -shlibs. Should
Oh wait, I can answer my own question by looking at the scripts in
/sw/are/lib/dpkg/info. They are indeed /bin/sh and it looks like it
was fink that make them thay way.
So for consistency, I agree.
By the way, there is an old comment of chrisp's in the docs which hints
that he was planning to
Folks, Max has released fink 0.9.9 which contains the code that knows about
splitoffs.
You can put your splitoff packages into the unstable tree, but I would
suggest adding
BuildDepends: fink (= 0.9.9)
to any such package. This will force the user to update fink first and
so the code will
This is a sporadic problem which hasn't been debugged yet. Try doing
fink reinstall automake, just by itself, and then run your big command
again.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
Bill Bumgarner [EMAIL PROTECTED] wrote:
Rsync's version has been bumped frequently over the last few months; from
2.5.0 to 2.5.4 happened in just a few+ months w/a revision released every
few weeks.
While the current release is available via:
http://samba.anu.edu.au/ftp/rsync/
Max Horn [EMAIL PROTECTED] wrote:
I think we might want to define a plan as to when we will consider
Fink to be 1.0. Some ideas of my own:
* package caching. It's just not acceptable that one has to wait
10-60 seconds before the actual command is processed.
* full shlibs support
Hmmm... using a browser I went to
ftp://ftp.gnome.org/pub/GNOME/stable/latest/sources
and what I see there is a bunch of files %n-%v.tar.gz, and no directories
%n.
On the other hand (and I didn't try this before) if I directly request
%n/%n-%v.tar.gz using wget or curl, I do get the file.
Hi all. As the experiences from the last week have shown, it is a bit tricky
updating things in the stable tree, particularly with regard to getting
all of the dependencies right.
I think it's important that we make the 0.4 release quite soon. Here's my
suggested strategy for doing this:
1)
When fink itself is being worked on, the way to test it is this:
1) checkout the fink module using cvs
2) within that fink module, run ./inject.pl
That will install the bleeding-edge fink package manager.
-- Dave
___
Fink-devel mailing list
Hi. I went back and looked at your message again, and it is certainly
over my head, which was why I didn't respond before. Others may have
had a similar reaction...
Have you tried Apple's new unix-porting list?
http://www.lists.apple.com/mailman/listinfo/unix-porting
-- Dave
I've just run fink fetch-all on a new system, and discovered that a number
of source files are no longer available where fink expects to find them.
Some of these may be stashed in the source part of our bindist, I haven't
checked that; but anybody trying to install these packages anew will be
Any new packages that you write, or updates to packages that you maintain,
are fine to check in to the unstable directory. The important things
to keep in mind about CVS are: (1) nothing goes to stable until it has
been throughly tested by other users, (2) except for immediately-committed
what is foo.dev? i've never heard of a .dev file...just curious.
It was a typo for foo.deb .
You can run fink validate on a .deb file and it will warn you about things
that have been placed in non-policy-compliant locations.
-- Dave
___
Martin Costabel wrote:
I have had positive user reports about the following packages which I
maintain and which are in unstable. I think they could be moved to
stable i nobody objects.
- agqt-0.9.1-1
- ispell-french-1.0-1
- ispell-german-20011124-1
(ispell-italian is broken ATM, because
Starting with fink-0.9.9, users who need to make a choice between different
packages to satisfy a dependency are given not only the names of the packages,
but also the Description field.
With this in mind, I have revised the Descriptions of several dozen packages
which appear in such choices. I
Rosalyn Lum [EMAIL PROTECTED] wrote:
Hi,
DDJ is working on a Lightweight Language CD and would like to possibly
include the MAC version of Python on the disk with the user
documentation. Is it OK if we include the Installer and copy your
documentation with with proper credits appearing
Let's back up for just a moment here.
If I sell a CD with GPL'd software, I am only required to provide the source
to my customers. So I can meet the requirement of the GPL by putting the
source on the CD. (Have you seen the CD's in question? I haven't, so maybe
they are doing this.)
You are certainly not the first to have noticed that fink's documentation
is inadequate.
Each time it comes up, the core fink developers seek volunteers from the
fink community to work on this. Perhaps people who don't have porting
skills but would like to help out.
So far, nobody is beating
Hi all.
To get db3-shlibs and db4-shlibs working correctly, I have made new revisions
of a couple of packages (python and python-nox in stable, bind9 in unstable).
Nothing should now Depend on db, db3, or db4; only BuildDepends is
allowed for those.
-- Dave
http://fink.sourceforge.net/doc/packaging/index.php
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
the package and jumping in
to help users where appropriate.
Other opinions about this would be welcome.
-- Dave
On Thu, 28 Feb 2002, David R. Morrison wrote:
I have written a system-ghostscript package, but I am undecided about
whether it should be included in fink or not.
As some
Hi. There was a discussion on #fink a week or so ago about what package
names to use when the shared libraries are incidental rather than a central
function of the package in question. The suggestion being discussed was
that there could be two naming conventions:
foo, foo-shlibs, and foo-bin
Ken Williams [EMAIL PROTECTED] wrote:
On Wednesday, April 17, 2002, at 08:02 AM, Kyle Moffett wrote:
I would like to try to help package Apache 2.0 in Fink after I
get it running on my own machine, overwriting Apple's version
1.3.
The other day I asked about packaging later versions
Max Horn wrote:
Also we uncovered this problem with the conversion to shlibs: So far,
if you e.g. depend on audiofile, but already depend on FOO which
already depended on that, you could just drop the audiofile
dependency. But if now FOO is converted to BuildDepend on audiofile,
and
Max Horn [EMAIL PROTECTED] wrote:
At 13:57 Uhr -0400 20.04.2002, David R. Morrison wrote:
Max Horn wrote:
Also we uncovered this problem with the conversion to shlibs: So far,
if you e.g. depend on audiofile, but already depend on FOO which
already depended on that, you could just
Max Horn [EMAIL PROTECTED] wrote:
Dave,
the new gdk-pixbuf-shlibs can't be smoothly upgraded while gdk-pixbuf
is installed - you moved some files (%i/lib/gdk-pixbuf/loaders/*.la )
from the master to the -shlibs splitoff.
Max
Thanks for pointing this out, Max.
I'm having trouble
OK, I put a different version of gdk-pixbuf into the shared-libraries/splitoff
module, in case somebody else wants to try out the one that gave the error
messages in my previous email.
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
Martin and Max wrote:
BTW, what sense does it make to split apt into several pieces? No other
package depends on it.
I don't see a reason for that, either... nor do I see one for
splitting libtool, but that's another story :-)
Well, it's all in preparation for the automated handling of
I'm one of the people who has not been able to get mozilla-0.9.9 running
(on either of my machines). I can use mozilla-0.9.8 just fine.
There were other reports of problems on the mailing lists, and Masanori
decided to stick with 0.9.8 for the fink 0.4.0 release.
-- Dave
OK, we can look at it.
I still have it installed. (It compiled and installed just fine.) I unlimit
the stacksize (just in case), and try to run it, and it silently dies with
no crash log and entry in the console log.
Pretty hard to debug, I have to admit...
-- Dave
OK, that might be the problem in my case. My ~/.mozilla directory is owned
by root, but how did that happen? And more importantly, how can we possibly
fix this in a fink context? We can't tell fink users if you want to run
mozilla, make sure that you and all other users on your machine first
OK, I can confirm that simply upgrading to mozilla-0.9.9-4 does not repair
the problem, but by manually running sudo chown drm:staff /Users/drm/.mozilla
I was able to get it to run.
Next, I tried manually deleting /Users/drm/.mozilla and then reinstalling
mozilla. This also worked fine. So I
Hi Jeremy. The line
Replaces: %n ( 1.2.2-2)
isn't actually needed, because a package is always free to Replace earlier
versions of itself.
Also, you should probably move
Depends: gnome-libs, gtkmm (= 1.2.8)
into the shlibs package. The reasoning is this: a user might uninstall the
main
I have made another group of splitoff packages for the shared libraries
project, deposited into the shared-libraries/splitoff module. I will
be moving these to the unstable tree after I have added the appropriate
BuildDepends entries to other packages, to make sure nothing breaks.
It might take
Great! Now maybe this can be fixed.
(By the way, the syntax is = = = , and it's what we got from dpkg.
What's confusing is that == is NOT part of this.)
-- Dave
___
Fink-devel mailing list
[EMAIL PROTECTED]
1 - 100 of 1174 matches
Mail list logo
