Re: [Fink-devel] Processing *.texi files

On Friday, January 18, 2002, at 07:06 PM, Max Horn wrote: > You are building the .info files, but not installing them (that is, > copy them to the correct place under %i). This should be done in your > installscript, and for normaly packages is done by their "make install" > target. Okay - I'

Re: [Fink-devel] How to represent package variants

What do we do about apt-get? On Friday, January 18, 2002, at 06:56 PM, Max Horn wrote: >> if default is true, ask user if they want to install dependencies. >> if default is undef, install if all dependencies are already installed. >> if default is false, only ask user if '-ask' is specified on th

[Fink-devel] Basic XML Processor for .info Files is Done!

I have completed a basic processor that allows you to take .info files such as: Package: foo Version: 1.0.1 Revision: 2 Depends: bar, x11 Maintainer: John Doe <[EMAIL PROTECTED]> and convert them to .xinfo files like: bar, x11 diffs will be posted on the feature request track

[Fink-devel] question about sub filename in Services.pm

I was just looking through the fink sources, and I wondered why we use a handwritten filename isolation routine, when the already installed File:: module was available? Should I fix this whenever it appears, check for problems, and submit a diff, or is it in there for some other reason? Just

Re: [Fink-devel] How to represent package variants

On Fri, 18 Jan 2002, Alexander Strange wrote: > Side note: "pine" and "pine-ssl" have another difference: "pine-ssl" > uses openldap. This probably counts as a bug, but I'm not going to > complain, because openldap takes too long to compile and I don't use > it. :) It's not a bug, it's a decisi

Re: [Fink-devel] How to represent package variants

Side note: "pine" and "pine-ssl" have another difference: "pine-ssl" uses openldap. This probably counts as a bug, but I'm not going to complain, because openldap takes too long to compile and I don't use it. :) On Friday, January 18, 2002, at 06:04 PM, Max Horn wrote: > This is not really muc

Re: [Fink-devel] How to represent package variants

On 19/1/02 6:48 AM, "Max Horn" <[EMAIL PROTECTED]> wrote: > > Package: foo > Version: 1.0 > Revision: 1 > ConfigureParams: --with-gargle-blaster > Depends: bar > DefaultOption: x11 > > Option: ssl > Depends: openssl > NotOption: ssl > ConfigureParams: --without-ssl > > Option: x11 > Depend

Re: [Fink-devel] Processing *.texi files

Ken Williams wrote: > >> I tried listing the .texi files (and later, the .info files) in the > >> InfoDocs field, but when I issue 'fink install' I get a "no such file > >> or directory" error. Clearly I'm misunderstanding the process. > There are *.info targets in the makefile, so I added a co

Re: [Fink-devel] Processing *.texi files

You are building the .info files, but not installing them (that is, copy them to the correct place under %i). This should be done in your installscript, and for normaly packages is done by their "make install" target. Max -- --- Max Horn Software D

[Fink-devel] cacheing

I just updated finlayd-cache, I think it bootstraps now. Time to resurrect the discussion on how the semantics should work... Also, can anybody see any serious problems with it? (Sorry, I'm not being particularly articulate, but it's 12:34am :P) -- Finlay __

Re: [Fink-devel] Processing *.texi files

On Friday, January 18, 2002, at 03:33 AM, Max Horn wrote: > At 0:46 Uhr -0600 18.01.2002, Ken Williams wrote: >> Hi, >> >> I apologize if this question is answered somewhere in the archives, >> but I couldn't find it (aside - is there a searchable archive >> somewhere? The one at geocrawler d

Re: [Fink-devel] How to represent package variants

At 18:31 Uhr -0500 18.01.2002, Kyle Moffett wrote: > On Friday, January 18, 2002, at 06:04 , Max Horn wrote: [...] >Sorry, this was just a kind of thinking out loud email, improving as >I went along, and really, whatever format we choose ought to be >reviewed here before anything solid is dec

Re: [Fink-devel] How to represent package variants

Just had another idea, for stuff like emacs-alpha, add an alpha variant, with a different version number, and make it non-default , so: if default is true, ask user if they want to install dependencies. if default is undef, install if all dependencies are already installed. if default is false,

Re: [Fink-devel] How to represent package variants

On Friday, January 18, 2002, at 06:04 , Max Horn wrote: At 17:08 Uhr -0500 18.01.2002, Kyle Moffett wrote: I was originally looking at something like this and I have thought a lot about it, one of the main reasons to use xml for a new format was the necessary complexity. On Friday, January 18, 2

Re: [Fink-devel] How to represent package variants

At 17:08 Uhr -0500 18.01.2002, Kyle Moffett wrote: >I was originally looking at something like this and I have thought a >lot about it, one of the main reasons to use xml for a new format >was the necessary complexity. > >On Friday, January 18, 2002, at 02:48 , Max Horn wrote: > >>So, regardless

Re: [Fink-devel] How to represent package variants

I was originally looking at something like this and I have thought a lot about it, one of the main reasons to use xml for a new format was the necessary complexity. On Friday, January 18, 2002, at 02:48 , Max Horn wrote: > So, regardless which format we choose, we want to support package > va

Re: [Fink-devel] How to represent package variants

At 15:06 Uhr -0500 18.01.2002, David R. Morrison wrote: >On the question of variants, there is one thing that is very important >to keep in mind: fink is a front-end to dpkg. > >This means that whatever scheme we adopt, there will need to be a translation >to dpkg names. > >If we are feeding depe

Re: [Fink-devel] DMG format

At 19:45 Uhr + 18.01.2002, Finlay Dobbie wrote: >On Thursday, January 17, 2002, at 08:54 pm, Max Horn wrote: > >>The only work around for this currently is to use this trick. > >Or use OmniWeb, methinks. ;-) Which I like a lot, and used for a long time, but I am now back to IE - it renderes

[Fink-devel] Re: plan and other package systems

Max et al: May I suggest that included in the plan is some sort of effort to establish a policy for other package systems to follow to avoid interference? Maybe this is more an issue for the other package systems out there, but some publicly-documented guidance wouldn't hurt, I think. I wrote u

Re: [Fink-devel] CPAN mirror

At 18:33 Uhr +0100 18.01.2002, Paul Gaborit wrote: >>Shouldn't we have a CPAN mirror? >> >>One could write a small script that takes >>http://www.cpan.org/MIRRORED.BY and generates a fink mirror file >>from that, I'd think. >> > >Ok. Wonderful, thanks a lot! I am now extending the _keys file t

Re: [Fink-devel] How to represent package variants

On the question of variants, there is one thing that is very important to keep in mind: fink is a front-end to dpkg. This means that whatever scheme we adopt, there will need to be a translation to dpkg names. If we are feeding dependency information to dpkg, for example, all of that informatio

Re: [Fink-devel] byte-compiling

On Friday, January 18, 2002, at 10:41 AM, David R. Morrison wrote: > First, are you making the built-in /usr/bin/emacs part of this system? > Will add-ons automatically get byte-compiled for it? That would be tough to do cleanly. In order for a given emacs binary to hook into the emacsen-common s

[Fink-devel] How to represent package variants

So, regardless which format we choose, we want to support package variants. The question is, how to do it best. There are multiple ways to go at it: 1) Have variants like we have now, with explicit names: * a "default" variant * a "ssl" variant * a "nox" variant * a "ssl-nox" variant

Re: [Fink-devel] DMG format

On Thursday, January 17, 2002, at 08:54 pm, Max Horn wrote: > The only work around for this currently is to use this trick. Or use OmniWeb, methinks. ;-) -- Finlay ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists

Re: [Fink-devel] info file format

At 10:24 Uhr -0800 18.01.2002, El JoPe Magnifico wrote: >On 18 Jan 2002, Randal L. Schwartz wrote: >>> (*) As a perl devotee, I understand your revulsion to forced use of >>> indentation, Randall. I'm of the same mind... but only with respect >>> to soruce code. This is not source code though

Re: [Fink-devel] CPAN mirror

>Shouldn't we have a CPAN mirror? > >One could write a small script that takes >http://www.cpan.org/MIRRORED.BY and generates a fink mirror file >from that, I'd think. > Ok. -- #!/usr//bin/perl -w use strict; # configuration my $mirror_dir = "/sw/lib/fink/mirror"

Re: [Fink-devel] byte-compiling

In the debian system, all of the flavors of emacs are made to depend on this emacsen-common package, and they all "Provide: emacsen". This includes xemacs. In the fink world, it might hopefully also include the Aqua version of emacs. After all, if I want to use an emacs addon, I probably want t

Re: [Fink-devel] byte-compiling

>Thanks! Just trying to absorb all of this! It looks like a very elegant >solution. > >I have a few questions. > >First, are you making the built-in /usr/bin/emacs part of this system? >Will add-ons automatically get byte-compiled for it? > >Second, do you anticipate that all of fink's emacs pac

[Fink-devel] CPAN mirror

Shouldn't we have a CPAN mirror? One could write a small script that takes http://www.cpan.org/MIRRORED.BY and generates a fink mirror file from that, I'd think. Max -- --- Max Horn Software Developer email: phone: (+49)

Re: [Fink-devel] byte-compiling

Christian Swinehart <[EMAIL PROTECTED]> wrote: > The solution that the debian project has settled on is to use the > emacsen-common package which handles byte-compiling for all installed > copies of emacs. So far I've converted the emacs20 and emacs21 packages > to work with it (and I would pr

[Fink-devel] mysql via fink; and phpmyadmin/webmin

Hi Andrei, fellow finkers. Andrei, you made a page at http://homepage.mac.com/macgurutemple/mysql_on_macosx.html where you explain how to build & run the latest MySQL version. Now, why not integrate these changes into fink, so that even more people can benefit from your work, and so that it's

Re: [Fink-devel] info file format

> "El" == El JoPe Magnifico <[EMAIL PROTECTED]> writes: El> (*) As a perl devotee, I understand your revulsion to forced use of El> indentation, Randall. I'm of the same mind... but only with respect El> to soruce code. This is not source code though, but rather essentially El> a config fil

[Fink-devel] plan

I want to start a PLAN file in CVS which contains the steps we plan for the future, and for which release each is targeted. We should also maybe fix what features we think are necessary for a 1.0 release. Pre 1.0: * shlibs support - I am going to work on this during weekend * two-level hierac

Re: [Fink-devel] Weird windowmaker 0.8.0 problem

At 10:43 Uhr +0100 18.01.2002, Martin Costabel wrote: >Max Horn wrote: > >> > install -d -m 755 >>/sw/src/root-windowmaker-0.80.0-1/sw/share/doc/windowmaker >> > bad command-line parameter -d >> > Usage: install >> > Where switches are: >> > -s --quiet make silent build >> >

Re: [Fink-devel] Weird windowmaker 0.8.0 problem

Max Horn wrote: > > install -d -m 755 /sw/src/root-windowmaker-0.80.0-1/sw/share/doc/windowmaker > > bad command-line parameter -d > > Usage: install > > Where switches are: > > -s --quiet make silent build > > -h --help show this message > > > > ### install failed, exit co

Re: [Fink-devel] Processing *.texi files

At 0:46 Uhr -0600 18.01.2002, Ken Williams wrote: >Hi, > >I apologize if this question is answered somewhere in the archives, >but I couldn't find it (aside - is there a searchable archive >somewhere? The one at geocrawler doesn't seem to be searchable). > >I'm packaging up some code that has a

[Fink-devel] Weird windowmaker 0.8.0 problem

One user got this problem twice on two different machines: > make[3]: Nothing to be done for `install-exec-am'. > make[3]: Nothing to be done for `install-data-am'. > make[3]: Nothing to be done for `install-exec-am'. > make[3]: Nothing to be done for `install-data-am'. > (cd /sw/src/root-w

Re: [Fink-devel] xfree86-server

Max Horn wrote: > > I wonder if there is any reason why we should keep the xfree86-server > package? Granted, it's supposed to be a "stable" base compared to > rootless, but rootless runs rock stable for me, too. I would even go further and claim there is no need for separate base and server pac