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

[Ken Williams]

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've created the following InstallScript:

InstallScript: <<
  mkdir -p %i/share/info
  cp libbow.info  %i/share/info/
  cp rainbow.info %i/share/info/
  make install prefix=%i
<<

I still get an error during 'fink install bow', though:

---
Preparing to replace bow 20010926-1 (using 
.../bow_20010926-1_darwin-powerpc.deb) ...
install-info: deleting entry `* Libbow: (libbow) ...'
install-info: no entry for file `rainbow'.
Unpacking replacement bow ...
Setting up bow (20010926-1) ...
* Libbow: (libbow).Bag-Of-Words Library
install-info: no section specified for new entry, placing at end

No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info: unable to determine description for `dir' entry - giving up
dpkg: error processing bow (--install):
  subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
  bow
### dpkg failed, exit code 1
Failed: can't install package bow-20010926-1
---

Does this mean there are errors in the .texi files themselves, or what's 
going on?  Is there somewhere I can read about this?

  -Ken


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Alexander Strange]

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 the 
>> command line.
>> Also, for different variants, instead of trying to piece together some 
>> scripts and stuff ourselves, we could use diff, and have the main 
>> version directly under  and then
>> 
>>  
>> 
>> 
>>  
>> 
>
——
Alexander Strange
[EMAIL PROTECTED]
"Gandalf, has your fondness for the hobbits' weed affected your mind?"
- The Lord Of The Rings Movie


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Kyle Moffett]

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 tracker shortly.

requires the XML::DOM module

Just doin my part,
Kyle Moffett


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Kyle Moffett]

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 want to help,
Kyle Moffett


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Jeff Whitaker]

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 decision.  Would you rather have
pine-ssl-openldap and pine-openldap packages?  At some point it becomes
ridiculous, and I just don't have time to maintain them all.

-Jeff


 --
Jeffrey S. Whitaker Phone  : (303)497-6313
Meteorologist   FAX: (303)497-6449
NOAA/OAR/CDC  R/CDC1Email  : [EMAIL PROTECTED]
325 BroadwayWeb: www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Alexander Strange]

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 much different from the current situation where we 
> have say a "wget" and a "wget-ssl" package. Technically, it would be 
> possible to take a single new-style package and convert it into 
> multiple old-style packages which would be functionaly identically.
——
Alexander Strange
[EMAIL PROTECTED]
"Gandalf, has your fondness for the hobbits' weed affected your mind?"
- The Lord Of The Rings Movie


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Jeremy Higgs]

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
>  Depends: x11
> NotOption: x11
>  ConfigureParams: --without-x
> 
> Option: gnome
>  ImpliesOption: x11
>  ConfigureParams: --with-panel
>  Depends: gnome
> NotOption: gnome
>  ConfigureParams: --without-gnome
> 
> NotOption: japanese
>  ConfigureParams: --without-japanese

That looks really good, actually!

> 
> Get what I mean? Note that the option "gnome" implies the option
> "x11". I am not sure how much sense I make, and there are probably
> holes in my thoguhts, so feel free to point them out :)

It seems pretty good to me, I can't think of anything else to add.

> 
> Now the next step. How does a user specify options?
> Mabye like configure does:
>  fink install foo --with-gnome --with-japanese
> Or like the current way:
>  fink install foo-gnome-japanese
> Or maybe completly different
>  fink install foo (gnome, japanese)

You could do that, (1st one, ala configure scripts), but also, if a user
just did "fink install foo", you'd probably want a choice as to what variant
you would like to install, i.e.:

Please choose one of the following:

[1] Default
[2] SSL-enabled
[3] X11-enabled
[4] Gnome-enabled
[5] etc

On top of that, you might want to add an option in the PREFIX/fink.conf file
to not have the option of choosing these variants?

One thing which might also be nice is if you pressed "1" for the 'menu'
above, and pressed 'tab', it should perhaps come up with a list of
dependencies?

> 
> And how do we map all this to dpkg names? One way would be to take
> the list of options, sort them alphabetically, and add concat them
> with the package name using "-".
> So the above examples would result in the .deb for foo-gnome-japanese-x11

That would be good, but it might be nice to distinguish from the ACTUAL
package, and the options that have been enabled, although I'm not sure
how... (One way may be to capitalise the package name, but that would
probably be a problem, as I've never seen a .deb file with capitals)

Thanks!


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Martin Costabel]

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 couple actions to
> the compilescript.  Now my complete .info file looks like this:
[]
> CompileScript: <<
>   CPPFLAGS='-traditional-cpp -I%p/include' ./configure %c
>   make
>   make libbow.info
>   make rainbow.info
> <<

Seems you don't move the *.info files to %p/share/info. You (or the
package makefile) have to move them yourself. InfoDocs is not like
DocFiles, it does not copy files, it only puts entries into
/sw/share/info/dir. 

-- 
Martin

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Max Horn]

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 Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] cacheing

[Finlay Dobbie]

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


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Ken Williams]

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 doesn't seem to be searchable).
>>
>> I'm packaging up some code that has a couple .texi documentation files 
>> that should get installed as docs.  I'm not very familiar with the 
>> .texi format, but I believe they need to be processed by 'makeinfo' 
>> into info-files.  Is there a field in the .info file that facilitates 
>> this?  I couldn't find one on 
>> http://fink.sourceforge.net/doc/packaging/reference.php .
>>
>> 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.
>
> InfoDocs is meant for installing the (texinfo, not fink) .info files 
> only. These get build by makeinfo from the .texi source files. 
> Normally, for any given package, their build system should do that 
> automatically. If for this package, the upstream maintainers didn't do 
> that, you'll just have to call makeinfo manually from your 
> compilescript.
>

For some reason I still can't figure it out.

There are *.info targets in the makefile, so I added a couple actions to 
the compilescript.  Now my complete .info file looks like this:


Package: bow
Description: Statistical document classification library/scripts
Version: 20010926
Revision: 1
Maintainer: Ken Williams <[EMAIL PROTECTED]>
Source: http://www-2.cs.cmu.edu/~mccallum/bow/src/bow-20010926.tar.gz
Homepage: http://www.cs.cmu.edu/~mccallum/bow
License: LGPL

DocFiles: README ChangeLog HACKING INSTALL NEWS TODO
InfoDocs: libbow.info rainbow.info
Patch: %f.patch

CompileScript: <<
  CPPFLAGS='-traditional-cpp -I%p/include' ./configure %c
  make
  make libbow.info
  make rainbow.info
<<


I verify during 'fink rebuild bow' that 'makeinfo' is indeed being 
called and the .info files are getting created.  However, I still get an 
error during
'fink install bow', here is the output:


[junior:lib/fink/mirror] ken% fink install bow
sudo /sw/bin/fink install bow
Reading package info...
Information about 268 packages read in 3 seconds.
dpkg -i /sw/fink/dists/local/main/binary-darwin-
powerpc/bow_20010926-1_darwin-powerpc.deb
(Reading database ... 13787 files and directories currently installed.)
Preparing to replace bow 20010926-1 (using 
.../bow_20010926-1_darwin-powerpc.deb) ...
install-info: no entry for file `libbow.texi'.
install-info: no entry for file `rainbow.texi'.
Unpacking replacement bow ...
Setting up bow (20010926-1) ...
install-info: read < /sw/share/info/libbow.info: No such file or 
directory
dpkg: error processing bow (--install):
  subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
  bow
### dpkg failed, exit code 1
Failed: can't install package bow-20010926-1


Where am I going wrong?

  -Ken


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Max Horn]

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 decided.

Sure thing, same for my examples, I just wondered if there was a 
particular reason for that line. No problem :)

[...]



At 18:44 Uhr -0500 18.01.2002, Kyle Moffett wrote:
>Just had another idea, for stuff like emacs-alpha, add an alpha 
>variant, with a different version number, and make it non-default 
>, so:

I don't particulary like that idea, now. variants/options should be just that.

In the case of emacs-alpha, we are really talking a radically 
different beast, with a Carbon base front end, and a different 
version number.


>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 the command line.

Something like this... need to think about it.


>Also, for different variants, instead of trying to piece together 
>some scripts and stuff ourselves, we could use diff, and have the 
>main version directly under  and then
>
>   
>
>
>   
>


Hm, I think in most cases, diff would be quite some overkill. I think 
the following should always be sufficient if the package is cleanly 
designed: "prepend", "append", "replace" ? The default would be 
"append" as it is currently.
In additon, a "diff" would be quite tricky, since the data it would 
be applied to would be different depending on which combination of 
variants is used, which essentially makes this not feasible, I think.


Which leads to another thing: order in which variants are applied. 
For scripts this can be important. So we should allow a way to change 
the order. Of course, if a variant depends on another, that already 
induces some sort of order, but we do not always have a dependency 
and still need the ordering... hm.



Next point: version specificatios. We can either use the dpkg format, 
like in "<<2.0" etc., or we use something custom, like I briefly 
mentioned in my previous post. Both have merits... , so many 
choices =)



Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Kyle Moffett]

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, only ask user if '-ask' is specified on the command 
line.

Also, for different variants, instead of trying to piece together some 
scripts and stuff ourselves, we could use diff, and have the main 
version directly under  and then








___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Kyle Moffett]

 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, 2002, at 02:48 , Max Horn wrote:

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

I would suggest something like:




...



How exatly do you intend the depends field to work? You only give empty examples

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 decided.



...





...



* a "ssl" variant
* a "nox" variant
* a "ssl-nox" variant


Instead use variant x, and have the default no x, no ssl, etc.

What I think.



1) obviously has the drawback that if you have 4 options to toggle, you have to list 16 varianst - ouch

2) is far more flexible, but what if we have options that contradict each other somehow? We'd need a way to specify that a certain option can't go with another one.

 for a variant in the same package
 for a variant in a different package


"package" could be an optional attribute and left away, the same for variant. So that one can write  or 


That was implied, in fact, in XML::DOM, if an attribute requested is missing, undef is returned.

Hm, above you mention a  element, now you use  - a good example of clash of different "believes" how XML should be used :) Compare the following three examples, all meant to represent the same:

1)



2)



3)


bar



(I meant before-version="2.0" to act the same as the current <<2.0 notation)
So, which one of these is "best" ? In my eyes, all have some pros and cons. Not an easy decision. But what I find important is that we try to use a single style throughout.


I definitely agree, and as above, whatever is chosen should be reviewed carefully, because we'll be stuck with it.

[...]

How about instead of ImpliesOption,

That was just a quick hack, never meant for real use :)

Same as most of the examples in my email, except they were in a different style of pseudo-code ;-)





Sure, although I don't see what purpose the outer  element serves.


Just one more thing to complicate coding, of course! :-)

NotOption: japanese
ConfigureParams: --without-japanese


Get what I mean? Note that the option "gnome" implies the option "x11". I am not sure how much sense I make, and there are probably holes in my thoguhts, so feel free to point them out :)


Now the next step. How does a user specify options?
Mabye like configure does:
fink install foo --with-gnome --with-japanese
Or like the current way:
fink install foo-gnome-japanese
Or maybe completly different
fink install foo (gnome, japanese)


How about this?

fink install foo
Use x11? [y/N] y   # Chose the default based on if dependancies are filled.
This will require installation of one of the following
1) xfree86 # this is if we decide to merge the packages
2) xfree86-system
3) xfree86-itools
Which one? (Enter 0 to choose not to install) [1] 1

Use gnome? [y/N] n
Use ssl? [Y/n] y

Installing xfree86...
[snip]

Though for many options, this could get tedious

Yes. That's why I would prefer a "default configuration". Or maybe an option that determines whether fink asks you or just uses the default...

Or, how about:

fink install foo			by default, will automatically use as many varieties as dependencies allow, or, 
So the above examples would result in the .deb for foo-gnome-japanese-x11

I agree, that would work, but the binary dist should only include the default variety, although if others were requested a lot, they might be added.

Sure, this wouldn't be such a big problem in fact (not counting compile & upload time now, but that's an entierly different matter).


Especially using the naming scheme you suggested

What do you guys think? Am I crazy? :)

Not really :-)

However, whatever we do, the variety featureset is going to need a lot of new code.

Yes and now, maybe not as much as you think.

This is not really much different from the current situation where we have say a "wget" and a "wget-ssl" package. Technically, it would be possible to take a single new-style package and convert it into multiple old-style packages which would be functionaly identically.

But still, it definitly is quite a sizeable task!


And I AM volunteering to do some of the coding, as long as I don't get too deep in over my head.  I'm familiar with advanced OOP, but I'm not done figuring out the full Perl syntax yet, so I hope I can help!

Sure, any help is appreciated. We are still at the design stage of course, but I consider that to be extremly important. The best implementation is worth

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

[Max Horn]

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 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
>
>I would suggest something like:
>
>
>   
>   
>   ...
>   
>   

How exatly do you intend the depends field to work? You only give 
empty examples


>   
>   
>   ...
>   
>   
>   
>   
>   
>   ...
>   
>
>
>>  * a "ssl" variant
>>  * a "nox" variant
>>  * a "ssl-nox" variant
>>
>
>Instead use variant x, and have the default no x, no ssl, etc.

What I think.



>>
>>1) obviously has the drawback that if you have 4 options to toggle, 
>>you have to list 16 varianst - ouch
>>
>>2) is far more flexible, but what if we have options that 
>>contradict each other somehow? We'd need a way to specify that a 
>>certain option can't go with another one.
>
> for a variant in 
>the same package
> for a variant 
>in a different package


"package" could be an optional attribute and left away, the same for 
variant. So that one can write  or 


Hm, above you mention a  element, now you use  - a good example of clash of different "believes" how XML 
should be used :) Compare the following three examples, all meant to 
represent the same:

1)



2)



3)

   
   bar



(I meant before-version="2.0" to act the same as the current <<2.0 notation)
So, which one of these is "best" ? In my eyes, all have some pros and 
cons. Not an easy decision. But what I find important is that we try 
to use a single style throughout.



[...]

>How about instead of ImpliesOption,

That was just a quick hack, never meant for real use :)


>
>   
>

Sure, although I don't see what purpose the outer  element serves.


>
>>
>>NotOption: japanese
>>   ConfigureParams: --without-japanese
>>
>>
>>Get what I mean? Note that the option "gnome" implies the option 
>>"x11". I am not sure how much sense I make, and there are probably 
>>holes in my thoguhts, so feel free to point them out :)
>>
>>
>>Now the next step. How does a user specify options?
>>Mabye like configure does:
>>   fink install foo --with-gnome --with-japanese
>>Or like the current way:
>>   fink install foo-gnome-japanese
>>Or maybe completly different
>>   fink install foo (gnome, japanese)
>>
>
>How about this?
>
>fink install foo
>Use x11? [y/N] y   # Chose the default based on if 
>dependancies are filled.
>This will require installation of one of the following
>   1) xfree86 # this is if we decide to 
>merge the packages
>   2) xfree86-system
>   3) xfree86-itools
>Which one? (Enter 0 to choose not to install) [1] 1
>
>Use gnome? [y/N] n
>Use ssl? [Y/n] y
>
>Installing xfree86...
>[snip]
>
>Though for many options, this could get tedious

Yes. That's why I would prefer a "default configuration". Or maybe an 
option that determines whether fink asks you or just uses the 
default...


>>And how do we map all this to dpkg names? One way would be to take 
>>the list of options, sort them alphabetically, and add concat them 
>>with the package name using "-".
>>So the above examples would result in the .deb for foo-gnome-japanese-x11
>
>I agree, that would work, but the binary dist should only include 
>the default variety, although if others were requested a lot, they 
>might be added.

Sure, this wouldn't be such a big problem in fact (not counting 
compile & upload time now, but that's an entierly different matter).



>>What do you guys think? Am I crazy? :)
>
>Not really :-)
>
>However, whatever we do, the variety featureset is going to need a 
>lot of new code.

Yes and now, maybe not as much as you think.

This is not really much different from the current situation where we 
have say a "wget" and a "wget-ssl" package. Technically, it would be 
possible to take a single new-style package and convert it into 
multiple old-style packages which would be functionaly identically.

But still, it definitly is quite a sizeable task!


>And I AM volunteering to do some of the coding, as long as I don't 
>get too deep in over my head.  I'm familiar with advanced OOP, but 
>I'm not done figuring out the full Perl syntax yet, so I hope I can 
>help!

Sure, any help is appreciated. We are still at the design stage of 
course, but I consider that to be extremly important. The best 
implementation is worthless with a bad design.


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

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

[Kyle Moffett]

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 
> 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

I would suggest something like:




...




...





...



>  * a "ssl" variant
>  * a "nox" variant
>  * a "ssl-nox" variant
>

Instead use variant x, and have the default no x, no ssl, etc.

> 2) Allow "options" that can be combined at will:
>  * the base settings, no options
>  * "ssl" - will enable ssl support
>  * "nox" - will build without X11
>  * "nognome" - will build without
>

Like above, I recommend that we ask the user what they want, then 
specifically enable features, like variants of x, gnome, ssl.

>
> 1) obviously has the drawback that if you have 4 options to toggle, you 
> have to list 16 varianst - ouch
>
> 2) is far more flexible, but what if we have options that contradict 
> each other somehow? We'd need a way to specify that a certain option 
> can't go with another one.

 for a variant in the 
same package
 for a variant in a 
different package

>
> Also, for 2), I don#t like to much the "nox" and "nognome" thingy, 
> that's sort of double negation - no I do not want no X-Window support, 
> ouch. So for 2, I'd imagine that we also provide a default set of 
> options, so that could be a list like "DefaultOptions: x, gnome" or so.
>

Not me neither! ;-)

>
> In either case, I also imagine the whole thing to use, to speak in OOP 
> terms, inheritance. What do I mean with this? Let's look at this 
> example (in pseudo code):
>
> Package: foo
> Version: 1.0
> Revision: 1
> ConfigureParams: --with-gargle-blaster
> Depends: bar
> DefaultOption: x11
> Option: ssl
>   ConfigureParams: --with-ssl
>   Depends: openssl
> Option: x11
>   ConfigureParams: --with-x
>   Depends: x11
>
>
> So, in all cases, the "bar" package is a dependency, and the 
> "--with-gargle-blaster" is passsed to configure.
> Now, there is a fundamental problem with this: what if a variant needs 
> to *remove* something from the default set? Ohm, not good. So, why not 
> use an if-else-approcah: Each variant doesn't just specify things for 
> when it is specified, but also a list of things to do when it is not 
> given. Look at this:
>
>
> 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
>   Depends: x11
> NotOption: x11
>   ConfigureParams: --without-x
>
> Option: gnome
>   ImpliesOption: x11
>   ConfigureParams: --with-panel
>   Depends: gnome
> NotOption: gnome
>   ConfigureParams: --without-gnome

How about instead of ImpliesOption,





>
> NotOption: japanese
>   ConfigureParams: --without-japanese
>
>
> Get what I mean? Note that the option "gnome" implies the option "x11". 
> I am not sure how much sense I make, and there are probably holes in my 
> thoguhts, so feel free to point them out :)
>
>
> Now the next step. How does a user specify options?
> Mabye like configure does:
>   fink install foo --with-gnome --with-japanese
> Or like the current way:
>   fink install foo-gnome-japanese
> Or maybe completly different
>   fink install foo (gnome, japanese)
>

How about this?

fink install foo
Use x11? [y/N] y   # Chose the default based on if 
dependancies are filled.
This will require installation of one of the following
1) xfree86 # this is if we decide to merge 
the packages
2) xfree86-system
3) xfree86-itools
Which one? (Enter 0 to choose not to install) [1] 1

Use gnome? [y/N] n
Use ssl? [Y/n] y

Installing xfree86...
[snip]

Though for many options, this could get tedious

>
> And how do we map all this to dpkg names? One way would be to take the 
> list of options, sort them alphabetically, and add concat them with the 
> package name using "-".
> So the above examples would result in the .deb for 
> foo-gnome-japanese-x11

I agree, that would work, but the binary dist should only include the 
default variety, although if others were requested a lot, they might be 
added.

>
> What do you guys think? Am I crazy? :)

Not really :-)

However, whatever we do, the variety featureset is going to need a lot 
of new code.

And I AM volunteering to do some of the coding, as long as I don't get 
too deep in over my head.  I'm familiar with advanced OOP, but I'm not 
done figuring out the full Perl syntax yet, so I hope I can help!

>

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

[Max Horn]

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 dependency information to dpkg, for example, all of
>that information will need to be translated to dpkg names.

Did you fully read my email? I actually talked about this in it :)
>
>
>A simple scheme of variants for a single fink package foo, could have
>variants A, B, C leading to dpkg packages foo-A, foo-B, foo-C, for
>example.  dpkg would be told that all of these "Provide: foo."

Yes.

>I start to get nervous about inheritance, though, under these circumstances.
>It could lead to some very complicated situations.


"Inheritance" as I suggested it is completly transparent to dpkg, it 
doesn't have to know anything about it. The inheritance thingy is 
just a way to prevent the need to specify options multiple times. 
This eases package creations, prevents one from forgetting to 
duplicate stuff, and also lowers the information redundancy.


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] DMG format

[Max Horn]

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 pages much faster. it has very good CSS support 
(something at which OW is incredibly bad). It displays many more 
pages correctly. It is *way* faster, OW always slows down to be slow 
as hell after some time. Last but not least, IE didn't crash a single 
time for me in the last weeks, while OW (4.0.5 till the latest 4.1 
beta, tried them all) usually crashed for me at least twice a day.
OW sure looks fine, and I like the crisp Cooca look of text displayed with it.

But with IE my productivity is way higher.


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Mat Caughron]

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 up a proposal for how PackageMaker pkg files and fink can get
along, and I'm eager to get your feedback on it.  I can't speak for Apple,
but if they are bundling their system software in pax-based packages,
then I doubt this issue will go away any time soon.

So here are my suggestions on how to make things work together well:
http://www.macgimp.org/fink

Now that I've got an email server glitch sorted out, I look forward to
working with you all directly on this list (and fink-user too.)

Best,



Mat Caughron
MacGIMP.org admin


> Message: 1
> Date: Fri, 18 Jan 2002 12:38:04 +0100
> To: [EMAIL PROTECTED]
> From: Max Horn <[EMAIL PROTECTED]>
> Subject: [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 hierachy inside trees - the long ago discussed move from
> a one level deep hierachy (gnome, games, editors, etc.) to a
> two-level one. We need to agree on a set of directories for this, I
> think, and some tools for the bin/srcdist will have to be adapted.
>
> * support for java packages
>
> * A way to sign .deb files (and maybe als .info files), and to
> automatically verify these signatures. This might not seems that
> important right now, but definitly will be in the future. I think we
> should use gnupg for this. At least all of the fink core developers
> will have to have a key, ideally all cross-signed with each other.
> Whenever somebody makes a binary release available, he'll sign it
> with his personal key. This is no easy thing, and probably will have
> to be discuessed in a full thread of its own.
>
> * Move to a new package format - yes or no, and which. This has to be
> carefully designed, I think.
>
>
> Post 1.0 (this doesn't mean we can't do it before, but it's not
> necessary for 1.0 either)
>
> * interactive mode
> * GUI
>
>
> Please mention things I forgot and which you think are important for
> future fink versions.
>
>
> Cheers,
>
> Max
> --
> ---
> Max Horn
> Software Developer
>
> email: 
> phone: (+49) 6151-494890
>
>


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] CPAN mirror

[Max Horn]

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 to include all the countries 
missing for CPAN, then I can add this.


Cheers,

Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[David R. Morrison]

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 information will need to be translated to dpkg names.

A simple scheme of variants for a single fink package foo, could have
variants A, B, C leading to dpkg packages foo-A, foo-B, foo-C, for
example.  dpkg would be told that all of these "Provide: foo."

I start to get nervous about inheritance, though, under these circumstances.
It could lead to some very complicated situations.

Just my 2/100th's of .  

   -- Dave

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] byte-compiling

[Christian Swinehart]

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 system, it has to change its load-path at 
compile time (or else it won't look in the directory where the 
fink-installed packages will be placed). It might be possible for a user 
to manually hook in by adding something to her .emacs file though. I'll 
look into it...

Otherwise we'd need to start installing things into /usr/share/emacs 
which seems to be a bit of a no-no.

> Second, do you anticipate that all of fink's emacs packages will be
> part of this system in the near future?  Right now it is tricky, with
> the emacs packages in stable NOT being part of this system.  It would
> be great if xemacs could be made part of the same system.  Also, I'm
> not sure what the role of emacs-alpha is.

The fink emacs packages are, as you can see, in a state of transition. 
Here's a quick summary:

The plain `emacs' and `emacs-nox' packages were maintained by Christoph 
based on apple's darwin port. I took over the emacs-nox in unstable a 
while back, updating it to version 21.1 (`emacs' is still at version 
20.7 b/c I haven't found a way to build 21.1 reliably under X). Neither 
of these uses emacsen-common and won't be updated to do so (see below).

emacs-alpha uses Andrew Choi's carbon patches to run either under the 
terminal or with a GUI under aqua. However, it's still pretty unstable. 
This is a problem for emacsen-common, because if any of the installed 
emacs binaries dies during byte-compilation of a package, the entire 
install process dies too. I think I'll wait for Andrew's next release 
before hooking in emacs-alpha.

emacs20, emacs20-nox, and emacs21-nox are the emacsen-common compliant 
versions of the plain packages (`emacs' and `emacs-nox'). The emacs20 
packages are pretty much unchanged from Christoph's versions aside from 
calling emacsen-common. These three packages are the future, and it may 
be time to phase out `emacs' and `emacs-nox', or turn them into bundles 
suggesting the use of emacs20{,-nox} or emacs21-nox.

Any thoughts on whether that's too rash?

-christian


___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] How to represent package variants

[Max Horn]

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


2) Allow "options" that can be combined at will:
  * the base settings, no options
  * "ssl" - will enable ssl support
  * "nox" - will build without X11
  * "nognome" - will build wihtout


1) obviously has the drawback that if you have 4 options to toggle, 
you have to list 16 varianst - ouch

2) is far more flexible, but what if we have options that contradict 
each other somehow? We'd need a way to specify that a certain option 
can't go with another one.

Also, for 2), I don#t like to much the "nox" and "nognome" thingy, 
that's sort of double negation - no I do not want no X-Window 
support, ouch. So for 2, I'd imagine that we also provide a default 
set of options, so that could be a list like "DefaultOptions: x, 
gnome" or so.


In either case, I also imagine the whole thing to use, to speak in 
OOP terms, inheritance. What do I mean with this? Let's look at this 
example (in pseudo code):

Package: foo
Version: 1.0
Revision: 1
ConfigureParams: --with-gargle-blaster
Depends: bar
DefaultOption: x11
Option: ssl
   ConfigureParams: --with-ssl
   Depends: openssl
Option: x11
   ConfigureParams: --with-x
   Depends: x11


So, in all cases, the "bar" package is a dependency, and the 
"--with-gargle-blaster" is passsed to configure.
Now, there is a fundamental problem with this: what if a variant 
needs to *remove* something from the default set? Ohm, not good. So, 
why not use an if-else-approcah: Each variant doesn't just specify 
things for when it is specified, but also a list of things to do when 
it is not given. Look at this:


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
   Depends: x11
NotOption: x11
   ConfigureParams: --without-x

Option: gnome
   ImpliesOption: x11
   ConfigureParams: --with-panel
   Depends: gnome
NotOption: gnome
   ConfigureParams: --without-gnome

NotOption: japanese
   ConfigureParams: --without-japanese


Get what I mean? Note that the option "gnome" implies the option 
"x11". I am not sure how much sense I make, and there are probably 
holes in my thoguhts, so feel free to point them out :)


Now the next step. How does a user specify options?
Mabye like configure does:
   fink install foo --with-gnome --with-japanese
Or like the current way:
   fink install foo-gnome-japanese
Or maybe completly different
   fink install foo (gnome, japanese)


And how do we map all this to dpkg names? One way would be to take 
the list of options, sort them alphabetically, and add concat them 
with the package name using "-".
So the above examples would result in the .deb for foo-gnome-japanese-x11


What do you guys think? Am I crazy? :)


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] DMG format

[Finlay Dobbie]

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/listinfo/fink-devel

Re: [Fink-devel] info file format

[Max Horn]

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, but rather essentially
>>>  a config file, and use of whitespace to indicate nesting makes far more
>>>  sense in that circumstance, IMHO.
>>
>>  Please don't second-guess me on this.  My objection has nothing to do
>>  with Perl.  My objection has to do with sensibility. :)
>>  To clue you gently in the right direction, how many spaces are in a tab?
>>  Careful how you answer that.
>
>Sorry, I shouldn't have made assumptions about the origins of your
>habits.  Nevertheless, your concept of sensibility is subjective:
>
>1. I personally make more mistakes when adding markup than I do with
>indentation.  No, this does not hold for everyone.
>
>2. I have a clue on telling my text editor not to reduce multiple
>blank spaces to tabs when dealing with certain files.
>No, this does not hold for everyone either.
>Note, YAML uses single-space as the per-level indent character,
>_not_ tab, so this is less of an issue than you are insinuating.
>
>Whatever, we can drop the discussion now (or take it off the list),
>since there's obviously zero support for the suggestion.  Which is...
>just fine.  =)

I wouldn't say there is zero support for it. Whatever we do, I think 
we should try to use something that already exists. This way, we can 
make use of existing code, and existing tools. Why reinvent the wheel.

So, it boils down to the question: which existing format to use? YAML 
and XML have been the only suggestions so far.

I have used XML in various projects, and know my way around it. This 
makes it "nicer" for me. I know it's a good format and easily capable 
of doing what we need. _However_, also because I know XML, I know 
that it's certainly not a catch-all solution, there are things for 
which it is better suited, and things for which it is less suited. So 
I try to be open-minded


Let me talk about something else here: in either case (or even if 
somebody suggests another format), this is only part of the job. The 
next thing is to design a specific format, making use of the 
container format we decide upon. This is certainly not a completly 
trivial thing if we want to do it right. also, we want to allow 
things like building multiple variants from a single package. So, we 
have to decide how to represent that in the file, and how to 
*implement* it, too.

So, we could actually even try to use *both*. What I have in mind 
right now is this: We first make sure the package reading code is 
completly seperated from the code processing it. Then we can add new 
package reader modules at will, e.g. one based on XML, one on YAML. 
We also keep the old one. Introduce new extensions for the files, 
like .yinfo and .xinfo or whatever.
The important thing is, all parse into the same data struct. 
Initially, the new formats would not support more features than 
before. but we can add support for new features gradually, and 
implement them in the backends. Old .info files will still keep 
working.

So, you now shout: "ah it is bad to have multiple different 
formats!". Well, I am not saying we have to do it, but the point is, 
if somebody is interested in it, it could easily be done. Since all 
formats map to the same internal representation, we can in fact 
trivially convert each format into the other (and convert the old 
.info files into the new format(s)). And if we do not want to work on 
both, well, just develop one, but still make the code as general as 
suggested above.

Oh, and generating .xinfo/.yinfo files should be implemented anyway, 
this could be used to "beautify" packages.




Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] CPAN mirror

[Paul Gaborit]

>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";
my $key_file = "$mirror_dir/_keys";
my $mirrored_by_file = "MIRRORED.BY";

# variables
my $current_server;
my %servers;

# script
open(MIRRORBY, "< $mirrored_by_file")
   or die "$mirrored_by_file: $!\n";
while() {
   chomp;
   next if (m/^\#/);
   if (m/^([a-z0-9A-Z.]+):/) {
 $current_server = $1;
 $servers{$current_server} = {};
 next;
   }
   if (m{^\s+([a-z_]+)\s+=\s+\"([^\"]+)\"}) {
 $servers{$current_server}{$1} = $2;
   }
}
close(MIRRORBY);

my %countries;

open(KEYS, "< $key_file")
   or die "$key_file: $!\n";
while() {
   chomp;
   if (m/^([a-z]{3}-[A-Z]{2}):\s+(.*)/) {
 $countries{$2} = $1;
   }
}
close(KEYS);

SERVER: foreach my $server (keys %servers) {
   # print "$server\n";
   if (! defined $servers{$server}{dst_location}) {
 warn "$server: no location !\n";
 next;
   }
   foreach my $country (keys %countries) {
 if ($servers{$server}{dst_location} =~ m/$country/i) {
   # print "\t$country -> $countries{$country}\n";
   $servers{$server}{key} = $countries{$country};
   next SERVER;
 }
   }
   warn "$server: country not found in '$servers{$server}{dst_location}'\n";
}

my %keys;
foreach my $server (keys %servers) {
   if (defined $servers{$server}{key}) {
 my $key = $servers{$server}{key};
 my $ftp_location =  $servers{$server}{dst_ftp};
 my $http_location =  $servers{$server}{dst_http};
 if (! defined $keys{$key}) {
   $keys{$key} = [];
 }
 if (defined $http_location) {
   push @{$keys{$key}}, $http_location;
 }
 if (defined $ftp_location) {
   push @{$keys{$key}}, $ftp_location;
 }
   }
}

my ($year, $month, $day) = (gmtime())[5,4,3];
$year += 1900;
$month++;
print "Timestamp: ", sprintf("%d-%02d-%02d", $year, $month, $day), "\n";
print "\n";
print "Primary: ftp://ftp.funet.fi/pub/languages/perl/CPAN/\n";;
foreach my $key (sort keys %keys) {
   foreach my $location (@{$keys{$key}}) {
 print "$key: $location\n";
   }
}

--

-- 
Paul Gaborit -- 
DR/GI -- 
Perl en français -- 

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] byte-compiling

[David R. Morrison]

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 to use it in every possible version.

  -- Dave

> >   It would
> >be great if xemacs could be made part of the same system.
>
> Indeed, but are the two even compatible enough to make this reasonable?

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] byte-compiling

[Max Horn]

>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 packages will be
>part of this system in the near future?  Right now it is tricky, with
>the emacs packages in stable NOT being part of this system.

The goal of course should be to get the current emacs into stable as 
soon as possible :)

I am using emacs-nox from unstable all the time, and it runs very 
stable and reliably for me (although I am must confess, I am not 
doing excessive testing, nothing much besides editing text)


>   It would
>be great if xemacs could be made part of the same system.

Indeed, but are the two even compatible enough to make this reasonable?


>   Also, I'm
>not sure what the role of emacs-alpha is.



Cheers,

Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] CPAN mirror

[Max Horn]

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) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] byte-compiling

[David R. Morrison]

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 presume that getting xemacs to consult it 
> as well wouldn't be too difficult...).
> 
>  From the point of view of an elisp package maintainer, the doc you 
> probably want to consult is /sw/share/doc/emacsen-
> common/debian-emacs-policy (which is a slightly modified copy of 
> debian's). For a working example, take a look at the crypt++el info 
> file & patch.
> 
> In the meantime I'll work on revising a fink-specific emacs policy and 
> will post it for comments shortly.
> 
> -christian

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 packages will be
part of this system in the near future?  Right now it is tricky, with
the emacs packages in stable NOT being part of this system.  It would
be great if xemacs could be made part of the same system.  Also, I'm
not sure what the role of emacs-alpha is.

  -- Dave



___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Max Horn]

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 even simpler to 
get it to run? Christoph has left the project, and since he was the 
MySQL maintainer, too, that space is now vacant, maybe you are 
interested?

In particular, we'd need to update the package to the latest MySQL 
version. Then, there should be a second new package, mysql-max, just 
like www.mysql.com has mysql-max. This would contain added features, 
like InnoDB (which your custom version includes, too).


If you are interested in working on this directly in fink, that would 
be most appreciated. If not, well, that's OK, too, but I figured I 
should ask you first since you obviously have experience with MySQL 
and actually use it!


Cheers,

Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] info file format

[Randal L. Schwartz]

> "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 file, and use of whitespace to indicate nesting makes far more
El> sense in that circumstance, IMHO.

Please don't second-guess me on this.  My objection has nothing to do
with Perl.  My objection has to do with sensibility. :)

To clue you gently in the right direction, how many spaces are in a tab?
Careful how you answer that.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] plan

[Max Horn]

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 hierachy inside trees - the long ago discussed move from 
a one level deep hierachy (gnome, games, editors, etc.) to a 
two-level one. We need to agree on a set of directories for this, I 
think, and some tools for the bin/srcdist will have to be adapted.

* support for java packages

* A way to sign .deb files (and maybe als .info files), and to 
automatically verify these signatures. This might not seems that 
important right now, but definitly will be in the future. I think we 
should use gnupg for this. At least all of the fink core developers 
will have to have a key, ideally all cross-signed with each other. 
Whenever somebody makes a binary release available, he'll sign it 
with his personal key. This is no easy thing, and probably will have 
to be discuessed in a full thread of its own.

* Move to a new package format - yes or no, and which. This has to be 
carefully designed, I think.


Post 1.0 (this doesn't mean we can't do it before, but it's not 
necessary for 1.0 either)

* interactive mode
* GUI


Please mention things I forgot and which you think are important for 
future fink versions.


Cheers,

Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Weird windowmaker 0.8.0 problem

[Max Horn]

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
>>  >  -h   --help   show this message
>>  >
>>  >  ### install failed, exit code 1
>>  >  Failed: installing windowmaker-0.80.0-1 failed
>>
>>  /usr/bin/install support -d; also, "which install" and "which make"
>>  give normal results for that user, as does "/usr/bin/install -d -m
>>  755 /tmp/foobar"
>>
>>  Obviously, from the error message, this was *not* the usual install
>>  program giving the error, but something different, but I fail to see
>>  what it might be. Note that I can't reproduce the problem over here.
>
>There is an "Install" script in windowmaker's source directory which
>talks just like this, but it has a capital I, so it shouldn't answer to
>"install", despite all case-insensitivity.

Indeed. Also note that it works fine for me, and some other people 
that reported successful installs of windowmaker. Hrm. Could this be 
an UFS issue? I don't see how, but I can't think of much else.



Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Weird windowmaker 0.8.0 problem

[Martin Costabel]

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 code 1
> >  Failed: installing windowmaker-0.80.0-1 failed
> 
> /usr/bin/install support -d; also, "which install" and "which make"
> give normal results for that user, as does "/usr/bin/install -d -m
> 755 /tmp/foobar"
> 
> Obviously, from the error message, this was *not* the usual install
> program giving the error, but something different, but I fail to see
> what it might be. Note that I can't reproduce the problem over here.

There is an "Install" script in windowmaker's source directory which
talks just like this, but it has a capital I, so it shouldn't answer to
"install", despite all case-insensitivity. 

-- 
Martin

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

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

[Max Horn]

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 couple .texi documentation 
>files that should get installed as docs.  I'm not very familiar with 
>the .texi format, but I believe they need to be processed by 
>'makeinfo' into info-files.  Is there a field in the .info file that 
>facilitates this?  I couldn't find one on 
>http://fink.sourceforge.net/doc/packaging/reference.php .
>
>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.

InfoDocs is meant for installing the (texinfo, not fink) .info files 
only. These get build by makeinfo from the .texi source files. 
Normally, for any given package, their build system should do that 
automatically. If for this package, the upstream maintainers didn't 
do that, you'll just have to call makeinfo manually from your 
compilescript.



>Any help?
>
>When I've got this all worked out, I'll submit the .info and .patch 
>files for inclusion in fink, as I think this project (libbow) hasn't 
>yet been ported and it took a lot of non-trivial work.

Thanks!


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Weird windowmaker 0.8.0 problem

[Max Horn]

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-windowmaker-0.80.0-1/sw/bin ; ln -s 
>../lib/GNUstep/Apps/WPrefs.app/WPrefs wprefs)
>   (cd /sw/src/root-windowmaker-0.80.0-1/sw/share/man/man1 ; for i in 
>geticonset getstyle seticons setstyle wcopy wdwrite wmaker wmsetbg 
>wsetfont wxcopy wxpaste ; do mv $i.1x $i.1 ; done )
>   (cd /sw/src/root-windowmaker-0.80.0-1/sw/share/man/sk/man1 ; for i 
>in geticonset getstyle seticons setstyle wdwrite wmaker wmsetbg 
>wsetfont wxcopy wxpaste ; do mv $i.1x $i.1 ; done )
>  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 code 1
>  Failed: installing windowmaker-0.80.0-1 failed


/usr/bin/install support -d; also, "which install" and "which make" 
give normal results for that user, as does "/usr/bin/install -d -m 
755 /tmp/foobar"

Obviously, from the error message, this was *not* the usual install 
program giving the error, but something different, but I fail to see 
what it might be. Note that I can't reproduce the problem over here.


Any idea?


Max
-- 
---
Max Horn
Software Developer

email: 
phone: (+49) 6151-494890

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] xfree86-server

[Martin Costabel]

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 packages. Right now you have to download the 50MB sources twice.
If I am not mistaken, the sources for the base package are from June
2001 and those for rootless from December, so it is rather surprising
that this mixture is working at all.

I am not speaking from experience, because I always use system-xfree86
and compile xfree86 from the cvs sources. But from various error
messages on the lists I get the impression that the present xfree86
packages are not working too well. The cvs sources are pretty bug-free
at the moment, so a snapshot taken right now should be usable for the
whole fink xfree86 package (but don't call the tarball stored at
sourceforge "snapshot"; this doesn't sound stable enough for some).

-- 
Martin

___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel