[Fink-devel] /sw/share/doc
I just noticed that various packages install multiple directories into /sw/share/doc (I am not talking about splitoffs which also cause this to some extent). For example, xmltv installs both /sw/share/doc/xmltv-0.5.8 and /sw/share/doc/xmltv. Likewise libxml2 (my own package) even installs three directories: libxml2, libxml2--2.5.4, libxml2-python-2.5.4 The cause is clear, one directory (libxml2 resp. xmltv) is created by the DocFiles: field, the other(s) by the package itself. I think we should try to avoid fix this whenever possible (and maybe should mention this in the file hierarchy policy). When I look for docs for a package, I don't want to search through multiple directories. In most cases fixing it is as simple as adding a line to the InstallScript, like mv %i/share/doc/%n-%v %i/share/doc/%n Look at the jpilot package which does this already. Comments, thoughts, opinions? A few other packages that are affected: * opensp (OpenSP vs. opensp3) * neon23 (neon23 vs. neon-0.23.7; probably other neonXY packages, too) * scrollkeeper (scrollkeeper vs. scrollkeeper-0.3.12) * libxslt (libxslt vs. libxslt-python-1.0.24) Bye, Max --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] More on dependencies...
On Tuesday, Feb 25, 2003, at 11:15 US/Eastern, Max Horn wrote: One should note that apt (and also dpkg, though with less power) already has a dependency engine which covers this case, as it deals with all the kinds of dependencies fink needs (minus build deps of course). Hence it might be a good idea to try to adapt its engine for fink (why reinvent the wheel?). Of course we'd have to interface perl and c(++) for this. We also would have to figure out how to hook into the apt-get code. We'd need to marry it with our code that deals with build deps, too (but that's covered in the next section). We also need to override apt's way of choosing which package to use to fulfill a multiple choice dependency (apt just use the first possible combination, it seems, while Fink tries to ask the user for his wishes). This all adds up to some complication. So while I still think we should at least consider it, it might not be worth the effort after all. In any case we can try to look at their sources and learn from them (how they solved various problems etc.). [... here I never finished what I wanted to write.] Dealing with build time === Several different approaches are possible... all have their issues and advantages The dumb way This is mostly how we do it now. But if we combine this with pkg-order, it might still be better than the current code... Roughly, what you do is this: when hooking into pkg-order, when it asks us for the deps of package foo, we check if a .deb is available for it. If yes, we return just the deps; if no we return the deps merged with the build deps (actually this is a bit more complicated for splitoffs, but we already have the code for all this anyway). Pro: this is straight forward to implement (we already do it this way afterall). Con: Is not very flexible; e.g. if package foo needs bar as a build dependency, and another pkg qux later conflicts with bar, we can't proceed, rather the user has to manually issues several commands (first building foo, then removing bar, then installing quy). Yuck. We have already determined problems with this method, and it seems crude, especially when better alternatives are available. The proper way -- Proper would be to (as I mentioned in the past) have a full fledged package orderer that is aware of the fact that build dependencies can be removed after they have been used. My hope is that it's possible to add support for this to pkg-order, maybe one could even get support from the pkg-order author(s) for this project. However, I consider it a hard piece of work to be done properly. Or possibly take code from pkg-order, add additional features, etc, and put it all into a perlmod. This would be the hardest, but I think that with a little thought we can come up with some kind of colored graph algorithm that makes the process a little easier. Also, when in doubt about multiple possible ways to fulfill a dependency, it should be possible to either let fink make a good (automatic) guess at it, *or* let fink ask the user what he prefers. Not sure how hard it would be to implement that atop pkg-order. Rather than using an external perl program, why don't we just adjust the code into a module and use the functions straight from fink. Pro: This is very powerful, and flexible, and gives the best user experience Con: Quite hard to implement in my estimation Yep, unfortunately. [Note: I wanted to go more into detail here, but never finished it] Chroot jail --- The idea is to build packages as we do it now, with the only exception that we first chroot into a custom root directory. For a chroot jail to work (i.e. in order to be able to run program in it), all necessary libraries (including system libraries) have to be existent inside the jail. This usually means copying these libraries (hard links might work, but only if the build dir is on the same drive as the system, which is not necessarily true for fink). And of course if you want to compile stuff, the header files and tools (compiler, linker, ...) are needed, too). Whee!!! Fun!!! I would recommend against hard links to directories, though. If we do this, we should make it optional, and add something like the following: A new info option 'Chroot' Packages with this tag defined are limited in whether they can be put into a Chroot or not. If it is not defined, then it doesn't matter. Package 'chroot-image-free': Should be available from apt for Fink. Chroot: Yes Essential: Yes Package 'chroot-image-apple' Must be built from a Mac OS X install for anything not-redistributable from Apple. Chroot: Yes Essential: Yes bootstrap: Installs packages with 'Essential: Yes' and without 'Chroot: Yes' 'fink --chroot install foo' would do the following: Make $builddir/chroot-foo-1.2.3-4 Install any packages with 'Essential: Yes' that do not have 'Chroot: No' into the
Re: [Fink-devel] More on dependencies...
On Tuesday, February 25, 2003, at 05:13 PM, Kyle Moffett wrote: Or possibly take code from pkg-order, add additional features, etc, and put it all into a perlmod. This would be the hardest, but I think that with a little thought we can come up with some kind of colored graph algorithm that makes the process a little easier. Just a note, what you're suggesting is what Max was suggesting. pkg-order is a perl mod, with a thin perl-script wrapper pretty much just for testing. =) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] More on dependencies...
At 17:13 Uhr -0500 25.02.2003, Kyle Moffett wrote: On Tuesday, Feb 25, 2003, at 11:15 US/Eastern, Max Horn wrote: Hm I wonder why your email client misreads my time zone like that =) [...] Yuck. We have already determined problems with this method, and it seems crude, especially when better alternatives are available. The problem with those better alternatives were listed by me below. Sometimes a crude but working solution is better than an hypothetical, not implemented elegant solution, hence I mentioned this possibility. The proper way -- Proper would be to (as I mentioned in the past) have a full fledged package orderer that is aware of the fact that build dependencies can be removed after they have been used. My hope is that it's possible to add support for this to pkg-order, maybe one could even get support from the pkg-order author(s) for this project. However, I consider it a hard piece of work to be done properly. Or possibly take code from pkg-order, add additional features, etc, and put it all into a perlmod. I never intended to use pkg-order as an external tool, that wouldn't be possible anyway. Rather I meant to use its code (which is under the GPL). THough ideally with as little changes as possible (mainly adding things, not changing them) to make migrating to new upstream versions possible. This would be the hardest, but I think that with a little thought we can come up with some kind of colored graph algorithm that makes the process a little easier. Uh, no idea how you envision that, but feel free to actually explain it. Don't stop at the oh we could maybe do it that and this way, it should be doabl, think it fully through, then present it. Cause there are dozens of pitfalls which are easy to overlook when designing this on paper... :-/ Also, when in doubt about multiple possible ways to fulfill a dependency, it should be possible to either let fink make a good (automatic) guess at it, *or* let fink ask the user what he prefers. Not sure how hard it would be to implement that atop pkg-order. Rather than using an external perl program, why don't we just adjust the code into a module and use the functions straight from fink. That was always my intention, though I didn't cleary mention it hear as such, sorry. [...] Bye, Max --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] gimp and libpng
Is there a reason why gimp [Build]Depends on libpng and not libpng3? This poses problems with the helpbrowser: It links with libpng.2.dylib, but also with libgtkxmhtml which in turn links with libpng.3.dylib. So both libraries are loaded at runtime, and the result is the infamous libpng warning: Application was compiled with png.h from libpng-1.2.5 libpng warning: Application is running with png.c from libpng-1.0.12 libpng error: Incompatible libpng version in application and library I just recompiled gimp with dependencies changed to libpng3[-shlibs], and the helpbrowser works now. I didn't have the time to test anything else. -- Martin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] problems with iostream.h
On Tuesday, February 25, 2003, at 06:03 PM, Moritz Zumbühl wrote: hello, /usr/include/gcc/darwin/3.1/g++-v3/backward/iostream.h:36: using declaration ` istream' introduced ambiguous type `istream' tokenizer.cc: In member function `virtual int yyFlexLexer::yylex()': ... (I added using namespace std; to /usr/include/FlexLexer.h and tokenizer.cc) How are you including iostream? A lot of times these types of things are cleaned up by using #include iostream instead of (the deprecated) #include iostream.h. Not sure if that would help in your particular case. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] More on dependencies...
On Tuesday, Feb 25, 2003, at 17:33 US/Eastern, Max Horn wrote:
At 17:13 Uhr -0500 25.02.2003, Kyle Moffett wrote:
On Tuesday, Feb 25, 2003, at 11:15 US/Eastern, Max Horn wrote:
Hm I wonder why your email client misreads my time zone like that =)
That IS odd! I just use Mail.app, so I have no clue. OH!!! Wait!
Mail.app
converted the time 'Tue, 25 Feb 2003 17:15:22 +0100' into my time zone,
so that I could compare to other mails I got from the list. ;-)
The proper way
--
Proper would be to (as I mentioned in the past) have a full fledged
package orderer that is aware of the fact that build dependencies
can be removed after they have been used. My hope is that it's
possible to add support for this to pkg-order, maybe one could even
get support from the pkg-order author(s) for this project. However,
I consider it a hard piece of work to be done properly.
Or possibly take code from pkg-order, add additional features, etc,
and put it all into a perlmod.
I never intended to use pkg-order as an external tool, that wouldn't
be possible anyway. Rather I meant to use its code (which is under the
GPL). THough ideally with as little changes as possible (mainly adding
things, not changing them) to make migrating to new upstream versions
possible.
I see, Benjamin pointed this out to me. Where do you find pkg-order?
Thanks.
This would be the hardest, but I think that with a little thought
we can come up with some kind of colored graph algorithm that makes
the process a little easier.
Uh, no idea how you envision that, but feel free to actually explain
it. Don't stop at the oh we could maybe do it that and this way, it
should be doabl, think it fully through, then present it. Cause there
are dozens of pitfalls which are easy to overlook when designing this
on paper... :-/
I just thought, Hmm, with a bunch of work, we could do it using a neat
colored directional graph and possibly make it easier to add features
to in the
future. You're right, though, about the difficulty of the project. I
have tried several simple directional graph schemes on paper, and most
of them failed miserably. The rest were just incredibly obtuse and
inefficient. I am not very good at graph theory, though, so I am sure
that I missed something(s).
I think that the most difficult part of this system is not the
build-{depends,conflicts}, but the issue
of versions, provides, and replaces. Here is another idea that
resolves multiple simultaneous
runs and multithreading issues:
For each package named on the command line
Create a stack containing only the named package and the action
(Build,Install,Remove).
While there are packages on the stack:
Lock the file /sw/var/fink.lock for writing
For each unsatisfied dependency
If a dependency is missing
Figure out how to fix it # -- Note here
Try to add it to the lock file
Push it onto the stack
If nothing has been pushed onto the stack
For each dependency in the lock file
If this level in the stack is the only one that has it locked
Remove it from the lock file
Unlock the file /sw/var/fink.lock
Otherwise go to the top level of the stack and continue
Please give your thoughts, ideas, input, etc. This is kind of a
preliminary idea,
so it is probably as full of holes as swiss cheese. It does need a way
of taking
various Provides, Replaces, etc, and determining what packages conflict
with
others, and what packages depend on others. This could likely be
solved with
a directional colored graph, where for each 'Depends:' item, there is a
list of
other packages that satisfy the dependency, etc, which is fairly simple
to
generate Then finding each dependency only requires a quick enumeration
of an array.
One of the problems with this is that it does not allow the system to
try other
dependencies while waiting for a lock on a package.
For prompting the user, this should be run once at the start without
actually
performing the actions and just assuming that they succeed. During that
cycle, when multiple possibilities are found, the user can be prompted
right
away. Using the graph described above, only the satisfiable
dependencies
would be listed. All the results would be cached for use during the
actual
build. As the build is progressing, the choices are verified again.
If any
choice requires modification of a package not identified to the user
initially,
AKA: Some other fink process installed or removed something, then prompt
about it.
Please give me any feedback at all on this stuff! Thanks!
Also, when in doubt about multiple possible ways to fulfill a
dependency, it should be possible to either let fink make a good
(automatic) guess at it, *or* let fink ask the user what he prefers.
Not sure how hard it would be to implement that atop pkg-order.
Rather than using an external perl program, why don't we just adjust
the code into a module and use the functions straight from fink.
That was always my
[Fink-devel] re: Send me the info again here
Hi, My name is Richard. I have discovered some secrets about making great money with an internet business. That is why I have reserved a FREE TOP position for you. However, you could lose that position to someone else if you don't secure it soon. Think about this. In the old style corporate model of business most people do not want to see you succeed because when you move up you block the path for everyone else. In our business model you can only advance by helping others move up. That makes your success very important to me. CLICK HERE NOW Here are some of the reasons why I know you can succeed in our business: Low Startup Costs No Selling, No Inventory, No Employees Proven Online state of the art Marketing System One on One Mentoring No Ceiling on Your Income You Don't Have to Know a lot about Computers Backed by a Well Established, Rock Solid Company The Secrets I Will Share with You Let me prove it at NO COST to you. You can join for free and TEST DRIVE this business with no obligation. I joined this business 5 months ago. Since then I have built a business which gives me personally over $5000.00 a month and is increasing every month. Would that make a difference in your life? Check out some of the reasons why I love this business and then come on over to my website and try it out for free. If you like what you see, become a member, then you and I can work together. I get to spend more time with my family. I don't need a job. I get to help other people. I can make my own schedule. Nobody can lay me off. I can sleep in whenever I want. My bills get paid on time. I can travel. I don't have to answer to anyone...I have freedom. If any of this appeals to you, please take a look at this amazing system. It's not going to cost you a cent to check it out. CLICK HERE NOW Thanks, Richard and the team. Zig Zigler: You can have everything in life you want, if you will just help enough other people get what they want. Remove yourself from this list by sending a message to [EMAIL PROTECTED] with the word "remove" in the subject line. liwucwocqcswvooidhjbkhxavjhbe --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
