Re: [gentoo-dev] GPL-2 vs GPL-2+
Yuri Vasilevski wrote: [...] > But at the benefit of having less confusion > for users about "What the heck is a GPL-2+?" for at last the same period > of time. [...] > So users will have to check what's the > meaning of that + at the end of GPL-2+, so I think it'll create much > more confusion than the work of updating packages with each new version > of GPL. I think naming them "GPL-2-only" and "GPL-2-or-later" will fix this issue, especially if the note mentioned by Diego 'Flameeyes' Pettenò will be added. If someone is really interested in knowing more about licenses or GPL he is likely to already know the "GPL 2 or later"-thing, while those not interested in it anyway are likely not to ask :-) Maybe the question arising could be: Did the author say "or later version" or did he say "or any later version" as maybe (IANAL) it means only "2.*" without that 'any' Something like that would make sense as I would want my software to be licensed under 2.* since they should be compatible but include "fixes" if a passage is unclear or creates problems in one or the other jurisdiction. Stefan Schweizer wrote: > I see little benifit in having GPL-2+ but a lot of potential confusion and a > lot of work for developers to check all pkges. What about creating a bug depending on some 11600 others for each package until it is fixed? (kidding) I agree on that, benefit would be rather small. IF a user really needs to know, wether it is 2.* or also a later version at his opinion it would for sure not be a problem to just look it up. On the other hand, changing the license should, if at all, be done rather at once than stepwise to avoid an inconsistend sceme, as I think this is what would create confusion... Ciao, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] net-misc/ltsp
Christian Faulhammer wrote: > Hi all, > > net-misc/ltsp will be removed on 15 Jan 2007, it has been hard masked > today. There is no maintainer, we have an open security issue [1], so it > will be punted. If someone steps to take it over, you know what to do. > > [1] http://bugs.gentoo.org/show_bug.cgi?id=142661 > > V-Li > Too bad, too; I just fixed a documentation bug[1][2] for it. Please let the GDP know if and when it is finally removed from the tree, so that we can update our documentation accordingly. [1] http://archives.gentoo.org/gentoo-doc-cvs/msg_04279.xml [2] http://bugs.gentoo.org/show_bug.cgi?id=158589 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: LAST RITES - rt2x00 beta 3
On Sat, 23 Dec 2006 00:01:23 + (UTC) Duncan <[EMAIL PROTECTED]> wrote: > Andrew Gaffney <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Fri, 22 Dec 2006 > 17:08:45 -0600: > > > Roy Marples wrote: > >> Hi list. > >> > >> Not often I issue a last rites, but here we go! > >> rt2x00-beta3 driver is going to be masked over the next few days > >> and then removed from portage around the end of January. > >> > >> This is at the request of upstream as they're mainly bored of > >> fixing compile and useability errors in beta3 with new kernels and > >> want to concentrate on beta4. > > > > Is it really necessary to notify people of a version bump? :P > > From what was written, it appears to be removal of the non-cvs > version, so it's not just a version bump. > Correct. beta3 will be removed before beta4 comes out. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] CAMERAS as USE_EXPAND
Hi all, I would like to add CAMERAS to the list of USE_EXPANDed variables. It is currently used by media-libs/libgphoto2, which can be built with/without support for the following photo cameras: adc65 agfa-cl20 aox barbie canon casio clicksmart310 digigr8 digita dimera directory enigma13 fuji gsmart300 hp215 iclick jamcam jd11 kodak konica largan lg_gsm mars minolta mustek panasonic pccam300 pccam600 polaroid ptp2 ricoh samsung sierra sipix smal sonix sonydscf1 sonydscf55 soundvision spca50x sq905 stv0674 stv0680 sx330z template toshiba ...which is IMO enough to warrant USE_EXPAND. For any objections, suggestions for a better name, etc. please also see bug 139884: http://bugs.gentoo.org/show_bug.cgi?id=139884 -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for net-wireless/ipw2100 and net-wireless/ipw2200
Christian Heim wrote: Heya, net-wireless/ipw2100 and net-wireless/ipw2200 are both kernel drivers built as an external package through portage. The codebase currently in portage is the same that is present in any up-to-date kernel tarball (2.6.x). For this reason I am suggesting, everyone migrates to the in-kernel drivers. They can be found here: Networking ---> Network device support ---> [*] Network device support Wireless LAN (non-hamradio) ---> [*] Wireless LAN drivers (non-hamradio) & Wireless Extensions Intel PRO/Wireless 2100 Network Connection Intel PRO/Wireless 2200BG and 2915ABG Network Connection These will also enable the in-kernel version of the ieee80211 driver. As per summary, both packages are going to get punted from the tree. Both will vanish around sometime next January (I'd say 30 days from today - which makes it 21th January 2007). And to leave those of you, who already use the in-kernel driver relaxed, the firmware images are not going to get removed as they are still needed for the in-kernel drivers. I switched to the in kernel ones without a problem. It does report itself as 1.1.4k in the gentoo-sources-2.6.19-r2 kernel though. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: portage idea - auto embed user patches
On Thu, 2006-12-21 at 21:47 -0600, Steev Klimaszewski wrote: > Steve Long wrote: > > Alec Warner wrote: > >> http://dev.gentoo.org/~solar/bashrc > >> > >> At the bottom of solar's bashrc you will find some lines dealing with > >> AUTOPATCH, I don't see the bashrc.autopatch in his dev space, but you > >> can probably request it from him. > >> > > Would it be possible to post that to this list? Then we've all got a > > searchable record of the best practise. > > > try http://dev.gentoo.org/~solar/portage_misc Interesting, but fairly lightweight. Mine handles re-autotooling when appropriate and marking the autopatch stage as completed: http://sources.catmur.co.uk/svn/repos/gentoo/phase_hooks.d/post_src_unpack/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for net-wireless/ipw2100 and net-wireless/ipw2200
Rémi Cardona wrote: On second thoughts, I'll raise a small objection to the removal. Latest gentoo version is 1.2.0 while the kernel (gentoo-sources-2.6.19-r2) says to contain 1.1.4. I know that difference isn't exactly huge, but still, it's a step backwards. The only changes from 1.1.4 to 1.2.0 which aren't related to the out-of-kernel build system are very small, will only affect a very small number of users (i.e. people who do wireless development) and are merged for 2.6.20. I don't think you will see any behavioural difference at all between 1.1.4 and 1.2.0 and I don't think this is a showstopper to removal. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] www-servers/axis -> commercial dependencies
* Vlastimil Babka <[EMAIL PROTECTED]> schrieb: > Enrico Weigelt wrote: > > Hi folks, > > > > I've noticed, axis has some commercial/non-free dependencies, ie. > > sun-javamail-bin and sun-jaf. Are there free replacements for them ? > > > > Yes, sun-javamail and sun-jaf are free (CDDL-licensed) replacements. > They were recently stabilized and should soon replace the -bin packages > in dependencies. Great :) It was really, really ugly getting tomcat emerge'd w/ all this commercial crap :( I had some talks w/ tomcat folks - they were some bit confused about the huge dependencies @gentoo and suggested using some of their (monolithic) packages instead. Could anyone explain where all these dependencies come from ? Are there perhaps some build conditionals which are not yet reflected in useflags ? thx -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /var/lib/init.d/* vs. pidfiles
* Roy Marples <[EMAIL PROTECTED]> schrieb:
> I'm going to stop you right there.
> Before claiming design problems in the init system, you could at least
> have the good grace to try out the most current available in portage
> where you would know
Well, I just sync'ed and `emerge -puD system` doesn't show up anything
todo, and I didn't mask out anything. So can I assume my init system
is up to date ?
> 1) status is now in /lib/rcscripts/init.d/{started,starting,etc}
Not at my site, just checked it.
> 2) A simple status call to the init script checks running daemons and
> returns either 0 or 1 appropriately allowing a sys admin to report on
> crashed services and possible take an automated action.
Yes, of course. But that's not what I'm actually looking for.
Recently I had the problem that some service died, which was necessary
for another one. While trying to start the other one, I ran into
trouble since the init system didn't know about the died service.
If the lookup would go directly to checking things like pidfiles
(where applicable) instead of the flag files, such problems would
(IMHO) be entirely fixed.
cu
--
-
Enrico Weigelt== metux IT service - http://www.metux.de/
-
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /var/lib/init.d/* vs. pidfiles
On Saturday 23 December 2006 14:50, Enrico Weigelt wrote: > Well, I just sync'ed and `emerge -puD system` doesn't show up anything > todo, and I didn't mask out anything. So can I assume my init system > is up to date ? i'm pretty sure he's talking about the 1.13 series which he's put a lot of time into > If the lookup would go directly to checking things like pidfiles > (where applicable) instead of the flag files, such problems would > (IMHO) be entirely fixed. well that's why it's just your opinion and not actual fact ... pidfiles are not completely reliable -mike pgpCkFI1CGKu9.pgp Description: PGP signature
Re: [gentoo-dev] /var/lib/init.d/* vs. pidfiles
On Sat, 23 Dec 2006 20:50:06 +0100 Enrico Weigelt <[EMAIL PROTECTED]> wrote: > * Roy Marples <[EMAIL PROTECTED]> schrieb: > > > > > I'm going to stop you right there. > > Before claiming design problems in the init system, you could at > > least have the good grace to try out the most current available in > > portage where you would know > > Well, I just sync'ed and `emerge -puD system` doesn't show up > anything todo, and I didn't mask out anything. So can I assume my > init system is up to date ? No you cannot. baselayout-1.13 is currently package.masked as there are still a few upgrade/downgrade issues to resolve with the 1.12 branch. However, it is unmasked on BSD profiles where it's enjoying great success. Hopefully in the new year it can be moved to ~ARCH. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /var/lib/init.d/* vs. pidfiles
* Mike Frysinger <[EMAIL PROTECTED]> schrieb: > > If the lookup would go directly to checking things like pidfiles > > (where applicable) instead of the flag files, such problems would > > (IMHO) be entirely fixed. > > well that's why it's just your opinion and not actual fact ... > pidfiles are not completely reliable maybe, but in which situations would it be worse than the current situation ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /var/lib/init.d/* vs. pidfiles
On Sat, 23 Dec 2006 20:50:06 +0100 Enrico Weigelt <[EMAIL PROTECTED]> wrote: > > 2) A simple status call to the init script checks running daemons > > and returns either 0 or 1 appropriately allowing a sys admin to > > report on crashed services and possible take an automated action. > > Yes, of course. But that's not what I'm actually looking for. > Recently I had the problem that some service died, which was necessary > for another one. While trying to start the other one, I ran into > trouble since the init system didn't know about the died service. > > If the lookup would go directly to checking things like pidfiles > (where applicable) instead of the flag files, such problems would > (IMHO) be entirely fixed. OK, read the code yourself as you don't belive me. http://sources.gentoo.org/viewcvs.py/baselayout/trunk/sh/rc-daemon.sh?rev=2441&view=markup But as it's Christmas I'll tell you anyway. A status check will examine every daemon started by start-stop-daemon in the service and check if it's still running by the process name/exec file and optional that it's running on the given pid in a pidfile if specified. If any listed daemons have crashed then the service is stopped and the stopped status is returned. Of course, a non root user can query the status too, but in this case only the init.d/started/service flag is checks as non root users cannot do the above. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /var/lib/init.d/* vs. pidfiles
* Roy Marples <[EMAIL PROTECTED]> schrieb: > baselayout-1.13 is currently package.masked as there are still a few > upgrade/downgrade issues to resolve with the 1.12 branch. However, it > is unmasked on BSD profiles where it's enjoying great success. > Hopefully in the new year it can be moved to ~ARCH. Ah, I'm on x86, so I don't have it yet. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Marking GPL-incompatible linkage?
* Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> schrieb: Hi, > Right now the aac useflag enable support for MP4v2 tags writing through > libmp4v2; the problem is that the library is licensed under MPL, while Amarok > is licensed under GPL, and they are likely not compatible one to the other, > which means it's impossible to redistribute binaries built this way. I'm not an license expert, but *IMHO* this only is an issue on static linking, not w/ dynamic linking. My argumentation would go like this: * The only possible conflict is that MPL'ed binaries are not allowed to link into GPL'ed ones. * What we call dynamic linking is actually loading some binary into an process and using its code/data - files are not touched * We do not actually link against an certain library, but instead against some *interface* (ie. defined by some .h file) - this is independent from an specific binary. * On an binary distribution, the two packages only sit somewhere in our filesystem (as well as an installed system) and aren't linked together in any way. => There's no impact on an binary distro (which would not be on the running system). To prohibit such an binary distro you could try two ways: a) prohibit MPL'ed and GPL'ed files together on the same media or computer. Totally stupid idea, IMHO. b) claim exclusive rights on an interface specification. -> not copyright, but patent issue -> at least in EU, such patents are illegal (although they exists) Just my 0.02 EUR ... cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] /var/lib/init.d/* vs. pidfiles
On Sat, 23 Dec 2006 22:08:15 +0100 Enrico Weigelt <[EMAIL PROTECTED]> wrote: > > baselayout-1.13 is currently package.masked as there are still a few > > upgrade/downgrade issues to resolve with the 1.12 branch. However, > > it is unmasked on BSD profiles where it's enjoying great success. > > Hopefully in the new year it can be moved to ~ARCH. > > Ah, I'm on x86, so I don't have it yet. Right. So the next time you want to discuss design issues in Gentoo, it might be a good idea to see if unstable and packaged.masked packages have already addressed any queries you may have. Here endeth todays lesson Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for net-wireless/ipw2100 and net-wireless/ipw2200
Daniel Drake wrote: > Rémi Cardona wrote: >> On second thoughts, I'll raise a small objection to the removal. >> Latest gentoo version is 1.2.0 while the kernel >> (gentoo-sources-2.6.19-r2) says to contain 1.1.4. I know that >> difference isn't exactly huge, but still, it's a step backwards. > > The only changes from 1.1.4 to 1.2.0 which aren't related to the > out-of-kernel build system are very small, will only affect a very small > number of users (i.e. people who do wireless development) and are merged > for 2.6.20. I don't think you will see any behavioural difference at all > between 1.1.4 and 1.2.0 and I don't think this is a showstopper to removal. Raymond's comment helped me migrate to the inkernel version and it works as you and phreak's predicted it would. I remove all my prior objections to the removal. :) Rémi -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Marking GPL-incompatible linkage?
On Saturday 23 December 2006 22:35, Enrico Weigelt wrote: > I'm not an license expert Then shut up. You're wrong, it's true for dynamic linking as well as for static linking. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpeMsYSzdn6T.pgp Description: PGP signature
[gentoo-dev] Wrong dependencies to postgresql
Hi folks, since jakub (as always) closes all my bugs, I'll report the issue to this list before completely giving up and never ever waste a single second on reporting bugs ... Lots of packages have an wrong/unnecessary dependency to postgresql. Three cases: a) probably traditionally depended on the whole postgresql, maybe since before libpq was an own package. ie. qt, dovecot, ... b) many apps (ie. webapps like bugzilla) have postgresql as dep., although they do not need it to be installed. (ie. bugzilla does not have to do anything directly w/ postgresql, since it uses perl-DBD for database access). Of course they maybe want to have access to some postgres database, but this obviously does not need an local server. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wrong dependencies to postgresql
Enrico Weigelt wrote: Hi folks, since jakub (as always) closes all my bugs, I'll report the issue to this list before completely giving up and never ever waste a single second on reporting bugs ... Enrico, you know exactly why he does that. Review the last bug you filed to me if you're claiming your clueless as to why. Lots of packages have an wrong/unnecessary dependency to postgresql. Three cases: a) probably traditionally depended on the whole postgresql, maybe since before libpq was an own package. ie. qt, dovecot, ... b) many apps (ie. webapps like bugzilla) have postgresql as dep., although they do not need it to be installed. (ie. bugzilla does not have to do anything directly w/ postgresql, since it uses perl-DBD for database access). Of course they maybe want to have access to some postgres database, but this obviously does not need an local server. cu Without providing a specific list of packages, nothing will be done with this. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wrong dependencies to postgresql
Doug Goldstein wrote: Enrico Weigelt wrote: Hi folks, since jakub (as always) closes all my bugs, I'll report the issue to this list before completely giving up and never ever waste a single second on reporting bugs ... Enrico, you know exactly why he does that. Review the last bug you filed to me if you're claiming your clueless as to why. http://www.google.com/search?hl=en&q=%22enrico+weigelt%22+troll&btnG=Google+Search Two pages on the US version of Google when you search for "Enrico Weigelt" and troll... http://www.google.de/search?q=%22enrico+weigelt%22+troll&ie=utf-8&oe=utf-8&rls=org.mozilla:de:official&client=firefox-a 6!!! pages on the German one.. You still wonder why some of your bugs get closed? Lots of packages have an wrong/unnecessary dependency to postgresql. Three cases: a) probably traditionally depended on the whole postgresql, maybe since before libpq was an own package. ie. qt, dovecot, ... b) many apps (ie. webapps like bugzilla) have postgresql as dep., although they do not need it to be installed. (ie. bugzilla does not have to do anything directly w/ postgresql, since it uses perl-DBD for database access). Of course they maybe want tohave access to some postgres database, but this obviously does not need an local server. cu Without providing a specific list of packages, nothing will be done with this. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Wrong dependencies to postgresql
Hi Enrico Enrico Weigelt wrote: Hi folks, since jakub (as always) closes all my bugs, I'll report the issue to this list before completely giving up and never ever waste a single second on reporting bugs ... ... and we're grateful to you for that. Lots of packages have an wrong/unnecessary dependency to postgresql. Three cases: Two. ( a) + b) '=' two cases ) a) probably traditionally depended on the whole postgresql, maybe since before libpq was an own package. ie. qt, dovecot, ... No. At least that's not the only reason. Since you reported a duplicated bug-report (bug #158978) for the issue I'm talking about, I thought you would have noted. But let's make it clear: There is this pg_config app which can be used by other apps to get includedir/libdir/cflags/ldflags/etc for the postgresql-libraries. This app has been installed by dev-db/postgresql until the latest minor version bumps (7.3.16, 7.4.14, 8.0.9-r1, 8.1.5-r1) for which we have an open stabilization bug (bug #152783). Until this bug is closed, stable packages which try to depend only on libpq instead of postgresql will eventually get an older version (depending on the arch) and fail. Therefore those bugs are invalid. b) many apps (ie. webapps like bugzilla) have postgresql as dep., although they do not need it to be installed. (ie. bugzilla does not have to do anything directly w/ postgresql, since it uses perl-DBD for database access). Of course they maybe want to have access to some postgres database, but this obviously does not need an local server. Thanks a lot for pointing this out. But be assured that we already know about the issue and we will solve it as soon as the mentioned versions of postgresql are stable on all archs together with the other dependencies. And we really don't need help to identify the packages in question, nor a bug-report for every single one of them, but thanks again. Thanks for reporting the issues and the interest in our work. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Wrong dependencies to postgresql
Enrico Weigelt napsal(a): > Hi folks, > > since jakub (as always) closes all my bugs, I'll report the issue > to this list before completely giving up and never ever waste a > single second on reporting bugs ... Thanks, you've wasted at least one hour of my time I spent duping those bugs and deleting the bugspam from my mailbox. You've already got your explanation on Bug 158950, so I don't see what's the point of this mail. Also, I'd expect people are able to use common sense when reporting bugs and do some research beforehand, but apparently that's not your case. To top the bugsmash, you've filed completely invalid Bug 158978 after all the above ~25 dupes, yet again proving that you didn't do any research at all. P.S. Oh, and as someone else already noted, you'd better fix your mailserver, it still seems a bit hacked... :P http://www.mail-archive.com/users@tomcat.apache.org/msg20585.html -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Marking GPL-incompatible linkage?
On Saturday 23 December 2006 17:34, Diego 'Flameeyes' Pettenò wrote: > On Saturday 23 December 2006 22:35, Enrico Weigelt wrote: > > I'm not an license expert > > Then shut up. > > You're wrong, it's true for dynamic linking as well as for static linking. agreed on both points -mike pgpAOof6Yol88.pgp Description: PGP signature
Re: [gentoo-dev] www-servers/axis -> commercial dependencies
On Sat, 2006-12-23 at 20:20 +0100, Enrico Weigelt wrote: > > Great :) > It was really, really ugly getting tomcat emerge'd w/ all this > commercial crap :( Blame upstream for using them. Granted the are somewhat optional more on that below. > I had some talks w/ tomcat folks Where? Who? Just curious. There are ant download targets for most of the deps, we just bypass. So it's not like the deps come from no where in a normal build from source. > - they were some bit confused > about the huge dependencies @gentoo and suggested using some > of their (monolithic) packages instead. I have tried to slim it down, but dropping certain deps to seem to change things that are activated or not within Tomcat. For example there seems to be some issues with the java5 USE flag. Either that, or some of the dropped deps when that flag is used is effecting the resulting catalina.jar. Who knows what other jars would be effected by dropping other deps. > Could anyone explain where all these dependencies come from ? Tomcat <=5.5.x has a ton of deps. There are these wonderful deps referred to in build.properties.default as Core Optional Libraries. I hate who ever decided to word it that way or call it that ;) I have tired to research if they are needed, what they do etc. If they effect the ending result. Example core optional libraries. Log4j? What's up with that Tomcat 5.5.x uses JULI by default. So that one alone I have yet to figure out why it's needed or should be around. Now consider this for a moment. Upstream is likely using binaries to build their binary version of Tomcat ;) So it's not like they are compiling all the stuff they are using to build Tomcat from source. Before they compile and ship Tomcat. We do it all from source. :) Which can explain extended deps right there. > Are there perhaps some build conditionals which are not yet > reflected in useflags ? I highly doubt it and with all the variables, you would likely break something and not know it. Till someone uses that feature or aspect and etc. Most are expecting the compiled from source on Gentoo version to be equivalent to the binary version, out of the box. The only thing I can say about the whole situation is they are working on releasing Tomcat 6.0.x in the next month or two. Tomcat 6.0.x has way less deps, and it's much clearer that the ones it has are needed. No core optional, or optional stuff. I might see about unmasking and versioning either alpha/beta the ebuild despite sources not being tagged :( So people can test it out and hopefully help get it released ASAP. As for 5.5.x, it's not clear if there will be further releases from upstream. It's got lots of legacy code and likely deps. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
