[clc-devel] opt dependencies
Hi all, driven by some questions regarding dependencies of opt ports on #crux, I've spent an hour to put together such a list. Some remarks: - only deps to opt ports are listed - the list is max. compressed, that mean if port A depends on B and C, but B depends on C, only B is listed for A - should be checked for errors ;) Useful ? Should we publish such a list on CLC ? prt-get ? btw, Per, I see one dependency problem in the base ports, vim, because gvim depends on gtk2 which is an opt port. One solution might be to split the port into two, vim and gvim. The first contains most of the stuff, gvim mainly the gvim binary and, of course, depends on / needs vim and should be located in opt or even contrib. kind regards Jürgen Port | Depends on ------------|------------------------------------- atk | glib2 audiofile | pkgconfig cvs | openssl emacs | xfree86 libtiff esound | audiofile fetchmail | openssl firefox | gtk2 libidl fontconfig | freetype2 expat pkgconfig gdk-pixbuf | gtk libtiff glib2 | gettext pkgconfig gtk | glib xfree86 gtk2 | atk pango imlib | xfree86 libtiff libungif libidl | glib2 libogg | pkgconfig libpng | pkgconfig libtiff | libjpeg libvorbis | libogg openssh | openssl pango | glib2 xfree86 pine | openssl ppp | openssl webfs | openssl wmaker | xfree86 libtiff libungif xchat | gtk2 openssl xfree86 | fontconfig libpng xmms | gtk libvorbis esound -- juergen.daubert@t-online.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/27/04 16:46 Juergen Daubert wrote: | Hi all, | | driven by some questions regarding dependencies of opt ports | on #crux, I've spent an hour to put together such a list. Hi Juergen, (late reply as usual) I did the same some time ago, it took me much more than an hour :) I manually compiled one package at a time form a /base only setup, restarting the process when compilation failed, adding one dep at a time. | Some remarks: | - only deps to opt ports are listed | - the list is max. compressed, that mean if port A depends on | B and C, but B depends on C, only B is listed for A | - should be checked for errors ;) I'll compare with my list and eventually send you diffs and comments, just in case I/you missed something. | Useful ? Should we publish such a list on CLC ? prt-get ? I think it's very useful, expecially for small installations. I expressed myself in the past in favour of adding deps into at least the /opt ports since: - - They're useful for the ones using prt-get - - The ones preferring straight pkgmk / prt-get install ~ are not affected by the dependency add-on So I express my vote for the last time, I won't bother Per or other people any longer on the topic, I promise :-) [cut: Juerge's deps list] Regards, Simone - -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQd348+whKqEdwqMRAncKAJ0SiwHmu7pemTnJ2BY5Zgp/ZKECwgCfUQ+q ydz/QVG14XYGYseznCnV8Dw= =0QeO -----END PGP SIGNATURE-----
On 02/27/04 16:46 Juergen Daubert wrote:
Hi all,
driven by some questions regarding dependencies of opt ports on #crux, I've spent an hour to put together such a list.
Some remarks: - only deps to opt ports are listed - the list is max. compressed, that mean if port A depends on B and C, but B depends on C, only B is listed for A - should be checked for errors ;)
Useful ? Should we publish such a list on CLC ? prt-get ?
Hi, I compared your dependency matrix with my previous one; given that mine is a bit outdated (30.12.2003) and I could have been drunk when I tested the dependencies, I think that they're essentially the same. Mine is a little shorter, I could compile some port without some optional lib (ie wmaker without libungif), but I think your list better reflects the packaged shipped within the ISO. For Per: I spotted another little inconsistency within the /opt and /base division: since pkgmk uses the unzip command I think unzip should go into /base Or, from another point of view, the package zip depends on unzip. That is the only addition I could find to Juergen's list. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Hi all,
driven by some questions regarding dependencies of opt ports on #crux, I've spent an hour to put together such a list.
Some remarks: - only deps to opt ports are listed - the list is max. compressed, that mean if port A depends on B and C, but B depends on C, only B is listed for A - should be checked for errors ;)
Useful ? Should we publish such a list on CLC ? prt-get ? I've added support for an external dependency file to my TODO list for
Hi Jürgen, On Fri, Feb 27, 2004 at 16:46:19 +0100, Juergen Daubert wrote: the next minor release. I hope I'll find the time to prepare a new release anytime soon. Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Fri, 5 Mar 2004, Johannes Winkelmann wrote:
Hi Jürgen,
Hi all,
driven by some questions regarding dependencies of opt ports on #crux, I've spent an hour to put together such a list.
Some remarks: - only deps to opt ports are listed - the list is max. compressed, that mean if port A depends on B and C, but B depends on C, only B is listed for A - should be checked for errors ;)
Useful ? Should we publish such a list on CLC ? prt-get ? I've added support for an external dependency file to my TODO list for
On Fri, Feb 27, 2004 at 16:46:19 +0100, Juergen Daubert wrote: the next minor release. I hope I'll find the time to prepare a new release anytime soon.
Sorry, I can't help myself ;) but all this talk about dependencies of course raises the well known question: is it time to add support for a "depends=(...)" thing to the Pkgfile/pkgmk? I sort of feel that prt-get has to introduce lot's of work arounds for pkgmk limitations to be able to provide features that most people would like to see, such as dependencies for opt ports. Some time ago I experimented with depends=(...) and I have a working prototype, in short: - The Pkgfile has a "depends=(xxx yyy zzz)" thing. - By default, the build will stop and an error will be issued if a dependency is not already installed. - Should a circular dependency be found the build will stop with an error. - Use --ignore-deps/-id to skip all checks. - Use --build-deps/-bd to build and install them all. - As usual, a users can set the corresponding PKGMK_XXX variables in pkgmk.conf to set the default behaviour. I don't mind this addition to pkgmk since it's quite small and easy to disable. The main problem is as usual formulating the policy, i.e. what should be specified there? What about optional/recommended/base deps, etc? However, I figure that since there haven't been much problems with the policy that we use today with prt-get's "Depends on:", we would just use that policy to begin with. In the future, I'd like to add dependencies to base ports (at least deps between base ports), mainly becuase that would help me when building the ISO. /Per
On Wed, 10 Mar 2004, Per Liden wrote: [...]
Some time ago I experimented with depends=(...) and I have a working prototype, in short:
btw, the patch for this is on a machine that I don't have access to at the moment. If there's any interest in the patch I could clean it up and make it available as soon as I get access to that machine (might not happen until next week). /Per
On Fri, 5 Mar 2004, Johannes Winkelmann wrote:
Hi Jürgen, [opt dep file & prt-get using it] Sorry, I can't help myself ;) but all this talk about dependencies of course raises the well known question: is it time to add support for a "depends=(...)" thing to the Pkgfile/pkgmk? I think having dependency listings in base and opt ports would be great. As far as I can tell, you have to introduce a path abstraction as well, or will it be necessary to specify 'contrib/libXY' where this is a valid
Hey Per, On Wed, Mar 10, 2004 at 10:33:31 +0100, Per Liden wrote: path in /usr/ports? Path abstraction seems pretty important to be to work well with httpup repos and private ports trees. Example: if pkgmk manages to install a dependency 'libjpeg' without knowing it's in /usr/ports/opt, shouldn't it for consistency reasons also allow doing something like cd /tmp pkgmk --package libjpeg -d -i -bd (downloading, building and installing package libjpeg with dependencies)? I might not be the most neutral person here, but I kind of liked the different levels pkgmk and prt-get were working. I don't mind at all if this functionality is in pkgutils, but I was wondering whether there should be two different tools. I kinda like pkgmk's simplicity to not look beyond a port directory.
Some time ago I experimented with depends=(...) and I have a working prototype, in short: - The Pkgfile has a "depends=(xxx yyy zzz)" thing. - By default, the build will stop and an error will be issued if a dependency is not already installed. - Should a circular dependency be found the build will stop with an error. - Use --ignore-deps/-id to skip all checks. - Use --build-deps/-bd to build and install them all. - As usual, a users can set the corresponding PKGMK_XXX variables in pkgmk.conf to set the default behaviour. cool. I'm looking forward to have a look at it.
I don't mind this addition to pkgmk since it's quite small and easy to disable. Mmmh. Recursive dependency resolving is small and easy in bash? ;-)
The main problem is as usual formulating the policy, i.e. what should be specified there? What about optional/recommended/base deps, etc? Optional dependencies would be great but often cause footprint differences. Currently, I try to make notes in the README file regarding optional dependencies and assume that people who want this optional feature are capable of coping with the possible footprint missmatch. Plus for example in subversion, there are two footprints (with/without apache) which are automagically used.
Looking forward to the prototype :-) Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Wed, 10 Mar 2004, Johannes Winkelmann wrote:
Hey Per,
Hi Johannes, [...]
I think having dependency listings in base and opt ports would be great. As far as I can tell, you have to introduce a path abstraction as well, or will it be necessary to specify 'contrib/libXY' where this is a valid path in /usr/ports? Path abstraction seems pretty important to be to work well with httpup repos and private ports trees.
Example: if pkgmk manages to install a dependency 'libjpeg' without knowing it's in /usr/ports/opt, shouldn't it for consistency reasons also allow doing something like cd /tmp pkgmk --package libjpeg -d -i -bd (downloading, building and installing package libjpeg with dependencies)?
To find out where a port is located my patch currently uses a PKGMK_SEARCH_PATH variable in pkgmk.conf. By default it contains something like "/usr/ports/base:/usr/ports/opt:/usr/ports/contrib". When searching for a dependency pkgmk will for each path in PKGMK_SEARCH_PATH do "find $path -path $dependency/Pkgfile" until the port is found. So, a user can add other port trees to the path list, and give them priority over other repos, etc. A "pkgmk --package xxx" feature would be possible to implement now that pkgmk knows where to looks for ports. [...]
I don't mind this addition to pkgmk since it's quite small and easy to disable. Mmmh. Recursive dependency resolving is small and easy in bash? ;-)
Actually, it's not as bad as one might think ;) /Per
On 03/10/04 10:33 Per Liden wrote: Hi,
Sorry, I can't help myself ;) but all this talk about dependencies of course raises the well known question: is it time to add support for a "depends=(...)" thing to the Pkgfile/pkgmk?
Wow, this would be an important change to pkgutils!
I sort of feel that prt-get has to introduce lot's of work arounds for pkgmk limitations to be able to provide features that most people would like to see, such as dependencies for opt ports.
I really like having a separate approach for basic things Vs. more user-friendly tools, and so far It worked very well (for me, at least). From the other side having a standard Pkgfile for base,opt and contrib would be really great. I think (and suggested it before) that having prt-get included in the official ISO, and integrating its documentation into the Handbook is a step in the right direction. That were my usual 2 cents, I'm sure whatever comes out from this "wind of change", it will be a good thing. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Hi Per, On Wed, Mar 10, 2004 at 10:33:31 +0100, Per Liden wrote:
On Fri, 5 Mar 2004, Johannes Winkelmann wrote:
Hi Jürgen,
On Fri, Feb 27, 2004 at 16:46:19 +0100, Juergen Daubert wrote: [...] I've added support for an external dependency file to my TODO list for the next minor release. I hope I'll find the time to prepare a new release anytime soon.
Sorry, I can't help myself ;) but all this talk about dependencies of course raises the well known question: is it time to add support for a "depends=(...)" thing to the Pkgfile/pkgmk?
[...]
However, I figure that since there haven't been much problems with the policy that we use today with prt-get's "Depends on:", we would just use that policy to begin with. In the future, I'd like to add dependencies to base ports (at least deps between base ports), mainly becuase that would help me when building the ISO. Do I understand this correctly that you will add dependencies to Pkgfiles of opt ports, and base ports later on? If yes, can you give a rough estimate of the date when these changes are going to be implemented? I don't want to put any pressure on you, I'm just wondering whether I should keep the "external dependency list file" feature in prt-get as I'm planning to release 0.5.5 soon-ish ;-).
I'd assume that the dependency list from Jürgen could be used to add this information to the Pkgfiles using a script; I can try to write such a script if you're missing the time (or if it's too boring ;-)). Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Mon, 15 Mar 2004, Johannes Winkelmann wrote: [...]
Do I understand this correctly that you will add dependencies to Pkgfiles of opt ports, and base ports later on? If yes, can you give a rough estimate of the date when these changes are going to be implemented?
Before I commit to anything I would like to just throw the patch and have it discussed (sorry, still don't have access to the machine/patch until thursday).
I don't want to put any pressure on you, I'm just wondering whether I should keep the "external dependency list file" feature in prt-get as I'm planning to release 0.5.5 soon-ish ;-).
Well, don't wait for me ;) If the depends=() feature is added it will not be until the next CRUX release, so your "external-deps" feature would still be useful for crux 1.3 users.
I'd assume that the dependency list from Jürgen could be used to add this information to the Pkgfiles using a script; I can try to write such a script if you're missing the time (or if it's too boring ;-)).
For the opt ports, I think I'll be able to fairly quickly add all depends=() lines manually. Juergen has already done the hard work. I can just cut and paste ;) However, such a script might be useful for converting prt-get-style "Depends on:" to a future pkgmk-style "depends=()". /Per
On Mon, 15 Mar 2004, Johannes Winkelmann wrote:
[...]
I don't want to put any pressure on you, I'm just wondering whether I should keep the "external dependency list file" feature in prt-get as I'm planning to release 0.5.5 soon-ish ;-).
Well, don't wait for me ;) If the depends=() feature is added it will not be until the next CRUX release, so your "external-deps" feature would still be useful for crux 1.3 users. I wasn't really asking for a depends= feature but for the addition of
Hi Per, On Tue, Mar 16, 2004 at 22:44:42 +0100, Per Liden wrote: the "# Depends on:" header to opt' Pkgfiles... Don't get me wrong here but prt-get doesn't work around limitations in pkgmk (as you put it before) but "missing" information in opt's Pkgfiles. In my opinion adding CLC style header to ports from base/opt would improve the user experience a lot; I'm not sure if the same applies for a dependency handling within pkgmk, since we already have a two tools (sports and prt-get) doing this, and AFAICT they work fine (please speak up if they are doing it the wrong way). So independent on the decision regarding pkgmk, adding a "# Depends on:" header would be nice, and I think you could even risk doing this between releases ;-). Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Thu, 18 Mar 2004, Johannes Winkelmann wrote:
Hi Per,
Hi Johannes,
On Mon, 15 Mar 2004, Johannes Winkelmann wrote:
[...]
I don't want to put any pressure on you, I'm just wondering whether I should keep the "external dependency list file" feature in prt-get as I'm planning to release 0.5.5 soon-ish ;-).
Well, don't wait for me ;) If the depends=() feature is added it will not be until the next CRUX release, so your "external-deps" feature would still be useful for crux 1.3 users. I wasn't really asking for a depends= feature but for the addition of
On Tue, Mar 16, 2004 at 22:44:42 +0100, Per Liden wrote: the "# Depends on:" header to opt' Pkgfiles...
Oh, I was under the impression that wasn't needed with the external-deps-file feature? /Per
On Thu, 18 Mar 2004, Johannes Winkelmann wrote:
Hi Per,
Hi Johannes,
On Mon, 15 Mar 2004, Johannes Winkelmann wrote:
[...]
I don't want to put any pressure on you, I'm just wondering whether I should keep the "external dependency list file" feature in prt-get as I'm planning to release 0.5.5 soon-ish ;-).
Well, don't wait for me ;) If the depends=() feature is added it will not be until the next CRUX release, so your "external-deps" feature would still be useful for crux 1.3 users. I wasn't really asking for a depends= feature but for the addition of
On Tue, Mar 16, 2004 at 22:44:42 +0100, Per Liden wrote: the "# Depends on:" header to opt' Pkgfiles...
Oh, I was under the impression that wasn't needed with the external-deps-file feature? Well, the external dependency list is just a workaround, and if it's not needed, I'd not release it at all; I kinda got the impression you weren't opposed to dependency listings in opt ports, but maybe I got
Hi Per, On Sat, Mar 20, 2004 at 14:48:53 +0100, Per Liden wrote: that wrong? Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Wed, 10 Mar 2004, Per Liden wrote: [...]
Some time ago I experimented with depends=(...) and I have a working prototype, in short: - The Pkgfile has a "depends=(xxx yyy zzz)" thing. - By default, the build will stop and an error will be issued if a dependency is not already installed. - Should a circular dependency be found the build will stop with an error. - Use --ignore-deps/-id to skip all checks. - Use --build-deps/-bd to build and install them all. - As usual, a users can set the corresponding PKGMK_XXX variables in pkgmk.conf to set the default behaviour.
I don't mind this addition to pkgmk since it's quite small and easy to disable. The main problem is as usual formulating the policy, i.e. what should be specified there? What about optional/recommended/base deps, etc?
Ok, here's the patch for the above. It was originally made for pkgutils 5.6 but the patch below is adjusted for 5.13. Please note that I haven't tested it much after the 5.13 adjustments. But it should at least give you an idea what I had in mind. /Per diff -ru pkgutils-5.13/pkgmk.conf pkgutils-5.13-with-deps/pkgmk.conf --- pkgutils-5.13/pkgmk.conf 2003-07-02 23:47:45.000000000 +0200 +++ pkgutils-5.13-with-deps/pkgmk.conf 2004-03-20 14:38:22.596107872 +0100 @@ -5,11 +5,15 @@ export CFLAGS="-O2 -march=i686 -pipe" export CXXFLAGS="-O2 -march=i686 -pipe" +PKGMK_SEARCH_PATH=(/usr/ports/base /usr/ports/opt /usr/ports/contrib) + # PKGMK_SOURCE_DIR="$PWD" # PKGMK_PACKAGE_DIR="$PWD" # PKGMK_WORK_DIR="$PWD/work" # PKGMK_DOWNLOAD="no" # PKGMK_IGNORE_FOOTPRINT="no" # PKGMK_NO_STRIP="no" +# PKGMK_IGNORE_DEPS="no" +# PKGMK_BUILD_DEPS="no" # End of file diff -ru pkgutils-5.13/pkgmk.in pkgutils-5.13-with-deps/pkgmk.in --- pkgutils-5.13/pkgmk.in 2003-12-16 18:18:21.000000000 +0100 +++ pkgutils-5.13-with-deps/pkgmk.in 2004-03-20 14:38:19.353600808 +0100 @@ -419,6 +419,61 @@ echo $RESULT } +check_dependencies() { + local DEP VISITED DIR DEP_FOUND CIRCULAR_DEPS ARGS + + if [ "$PKGMK_IGNORE_DEPS" = "yes" ] || [ "${depend[*]}" = "" ]; then + return + fi + + info "Resolving dependencies: ${depend[*]}" + + export PKGMK_DEPS_VISITED="$PKGMK_DEPS_VISITED $name" + + for DEP in ${depend[*]}; do + for VISITED in $PKGMK_DEPS_VISITED; do + if [ "$DEP" = "$VISITED" ]; then + for VISITED in $PKGMK_DEPS_VISITED; do + CIRCULAR_DEPS="${CIRCULAR_DEPS}${VISITED} -> " + done + error "Circular dependency found (${CIRCULAR_DEPS}${DEP})." + error "Building '$TARGET' failed." + exit 1 + fi + done + + pkginfo -l $DEP &> /dev/null + if [ $? != 0 ]; then + if [ "$PKGMK_BUILD_DEPS" = "no" ]; then + error "Dependency '$DEP' not installed." + error "Building '$TARGET' failed." + exit 1 + fi + + DEP_FOUND="no" + for DIR in ${PKGMK_SEARCH_PATH[@]}; do + if [ -f $DIR/$DEP/$PKGMK_PKGFILE ]; then + if [ "$PKGMK_DOWNLOAD" = "yes" ]; then + ARGS="-d -i" + else + ARGS="-i" + fi + info "Entering directory '$DIR/$DEP'." + (cd $DIR/$DEP && $PKGMK_COMMAND $ARGS) || exit 1 + info "Leaving directory '$DIR/$DEP'." + DEP_FOUND="yes" + fi + done + + if [ "$DEP_FOUND" = "no" ]; then + error "Dependency '$DEP' not found in search path." + error "Building '$TARGET' failed." + exit 1 + fi + fi + done +} + interrupted() { echo "" error "Interrupted." @@ -438,6 +493,8 @@ echo " -r, --recursive search for and build packages recursively" echo " -d, --download download missing source file(s)" echo " -do, --download-only do not build, only download missing source file(s)" + echo " -id, --ignore-deps do not check dependencies" + echo " -bd, --build-deps build and install dependencies" echo " -utd, --up-to-date do not build, only check if package is up to date" echo " -uf, --update-footprint update footprint using result from last build" echo " -if, --ignore-footprint build package without checking footprint" @@ -466,6 +523,10 @@ -do|--download-only) PKGMK_DOWNLOAD="yes" PKGMK_DOWNLOAD_ONLY="yes" ;; + -id|--ignore-deps) + PKGMK_IGNORE_DEPS="yes" ;; + -bd|--build-deps) + PKGMK_BUILD_DEPS="yes" ;; -utd|--up-to-date) PKGMK_UP_TO_DATE="yes" ;; -uf|--update-footprint) @@ -565,6 +626,7 @@ if [ "`build_needed`" = "no" ] && [ "$PKGMK_FORCE" = "no" ]; then info "Package '$TARGET' is up to date." else + check_dependencies download_source build_package fi @@ -598,6 +660,8 @@ PKGMK_RECURSIVE="no" PKGMK_DOWNLOAD="no" PKGMK_DOWNLOAD_ONLY="no" +PKGMK_IGNORE_DEPS="no" +PKGMK_BUILD_DEPS="no" PKGMK_UP_TO_DATE="no" PKGMK_UPDATE_FOOTPRINT="no" PKGMK_IGNORE_FOOTPRINT="no"
Hey, On Fri, Feb 27, 2004 at 16:46:19 +0100, Juergen Daubert wrote:
Hi all,
driven by some questions regarding dependencies of opt ports on #crux, I've spent an hour to put together such a list.
Some remarks: - only deps to opt ports are listed - the list is max. compressed, that mean if port A depends on B and C, but B depends on C, only B is listed for A - should be checked for errors ;)
Useful ? Should we publish such a list on CLC ? prt-get ? There's a test version (0.5.5pre1) available at http://www.hta-bi.bfh.ch/~winkj/files/crux/prt-get-0.5.5pre1.tar.gz
The dependency file I'm using is just a copy of Jürgen's listing with pipe ('|') symbols replaced with colons (':'): http://www.hta-bi.bfh.ch/~winkj/files/crux/opt.dependencies Just add the following to prt-get.conf: --- depfile /var/lib/pkg/opt.dependencies --- Happy testing (appreciated ;-)) Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 03/06/04 00:16 Johannes Winkelmann wrote:
There's a test version (0.5.5pre1) available at http://www.hta-bi.bfh.ch/~winkj/files/crux/prt-get-0.5.5pre1.tar.gz
The dependency file I'm using is just a copy of Jürgen's listing with pipe ('|') symbols replaced with colons (':'): http://www.hta-bi.bfh.ch/~winkj/files/crux/opt.dependencies
Just add the following to prt-get.conf: --- depfile /var/lib/pkg/opt.dependencies ---
Happy testing (appreciated ;-)) Regards, Johannes
That's really great, it would help me a lot with the automated build procedure. A great thank you as usual is not enough! So far so good with the testing. Regarding the format of the dep file, i suggest something similar: prt-get printf "%n;: %e\n"|grep ": ."|column -t -s ";" > all.deps since it's a bit more compact (exp. for ports with many deps) I noticed your code should handle this format as well. best regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
On Fri, 27 Feb 2004, Juergen Daubert wrote: [...]
btw, Per, I see one dependency problem in the base ports, vim, because gvim depends on gtk2 which is an opt port. One solution might be to split the port into two, vim and gvim. The first contains most of the stuff, gvim mainly the gvim binary and, of course, depends on / needs vim and should be located in opt or even contrib.
The gtk2 dependency in the vim port is admittedly ugly. I have so far just ignored the problem in the hope that it will not cause to much problems. If I was forced to deal with this issue I tend to lean towards ripping gvim out of base/vim and let someone else create a contrib/gvim port. Would someone be willing to maintain a contrib/gvim port? /Per
Per Liden said|sagte:
If I was forced to deal with this issue I tend to lean towards ripping gvim out of base/vim and let someone else create a contrib/gvim port. Would someone be willing to maintain a contrib/gvim port?
Is anybody using gvim at all? Markus. -- Markus Ackermann <maol@symlink.ch> http://maol.ch/ http://symlink.ch/
On Tue, Mar 09, 2004 at 06:03:50PM +0100, Markus Ackermann wrote:
Per Liden said|sagte:
If I was forced to deal with this issue I tend to lean towards ripping gvim out of base/vim and let someone else create a contrib/gvim port. Would someone be willing to maintain a contrib/gvim port?
Is anybody using gvim at all?
That's a good question, but if we need an gvim port and cannot find another volunteer, I'll maintain one. Greetings Jürgen -- juergen.daubert@t-online.de
On Tue, 9 Mar 2004, Juergen Daubert wrote:
On Tue, Mar 09, 2004 at 06:03:50PM +0100, Markus Ackermann wrote:
Per Liden said|sagte:
If I was forced to deal with this issue I tend to lean towards ripping gvim out of base/vim and let someone else create a contrib/gvim port. Would someone be willing to maintain a contrib/gvim port?
Is anybody using gvim at all?
That's a good question, but if we need an gvim port and cannot find another volunteer, I'll maintain one.
I'm not a frequent gvim (nor vim) user myself but I was under the impression that gvim was used by quite lots of people, I guess I was wrong. In any case, I guess a gvim port will pop up as soon as someone who is frequently using it finds out that it's not in base/vim anymore. However, to avoid lot's of confusion/questions/flames from gvim users I'd like to wait with removing gvim from base/vim until the next ISO release. Sounds reasonable? /Per
participants (5)
-
Johannes Winkelmann -
Juergen.Daubert＠t-online.de -
Markus Ackermann -
Per Liden -
Simone Rota