sqlite does not really depend on the version of the library used by ICU. Generated with FreeBSD Port Tools 0.99
mi 2011-05-26 14:46:47 UTC FreeBSD ports repository Modified files: databases/sqlite3 Makefile Log: Relax the requirement for icudata's shared library number. Submitted: self Approved by: maintainer PR: 157330 Revision Changes Path 1.59 +1 -1 ports/databases/sqlite3/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
imho this is a bad idea because when a bump will be done on icu it will be more complicated to chase this bump on sqlite. Would be better to keep it like it was. So that icu maintainer (me :)) we be able to know what ports to bump. regards, Bapt
Hello. Maybe you're right. But, sqlite works equally well when the user has already installed ICU.3 or ICU.4. Depending sqlite in this case does not require the user to update ICU library at the same time upgrading sqlite. On Fri, May 27, 2011 at 15:45, Baptiste Daroussin <bapt@freebsd.org> wrote: > imho this is a bad idea because when a bump will be done on icu it > will be more complicated to chase this bump on sqlite. > > Would be better to keep it like it was. So that icu maintainer (me :)) > we be able to know what ports to bump. > > regards, > Bapt >
2011/5/27 Pavel Volkov <pavelivolkov@googlemail.com>: > Hello. > Maybe you're right. But, sqlite works equally well when the user has already > installed ICU.3 or ICU.4. Depending sqlite in this case does not require the > user to update ICU library at the same time upgrading sqlite. > There is no more ICU 3 now only icu 4 and the link library is (currently :) ) libicu.so.46 so if upgrade occurs and sqlite is not bumped sqlite will just fail. Bapt
On 27.05.2011 14:07, Pavel Volkov wrote: > > Would be better to keep it like it was. So that icu maintainer (me :)) > > we be able to know what ports to bump. The ICU-maintainer can already know that -- all dependencies are indexed in ports/INDEX. Yours, -mi
2011/5/27 Mikhail T. <mi+thun@aldan.algebra.com>: > On 27.05.2011 14:07, Pavel Volkov wrote: > >> Would be better to keep it like it was. So that icu maintainer (me :)) >> we be able to know what ports to bump. > > The ICU-maintainer can already know that -- all dependencies are indexed in > ports/INDEX. > > Yours, > > -mi > Not all only the default one. So basically sqlite will always be linked to .so.46 so why removing this from the ports? this is the way we have always work for library dependency, Changing this will bring nothing has if icu is bumped sqlite will need to be bumped because it will be linked to .so.46 which will be away. regards, Bapt
On 27.05.2011 15:18, Baptiste Daroussin wrote: > Not all only the default one. ? > So basically sqlite will always be linked to .so.46 so why removing > this from the ports? Here is the scenario, that my campaign for eliminating the explicit shared library versions from most LIB_DEPENDS aims to prevent (icudata is used as an example -- other examples abound: jpeg, png, expat...) 1. Update the ports tree. 2. Build foo, that depends on icudata. 3. Wait two weeks. 4. Update the ports tree. 5. Build bar, that depends on icudata. If the icudata happened to get upgraded during these two weeks, building bar becomes impossible until one upgrades icu, which requires upgrade of foo... When foo is one's entire desktop, this becomes prohibitive... portupgrade helps here by shoveling old version of libicudata into a special directory, but that means waste of diskspace and run-time RAM -- because instances of bar and of foo will be using different versions of libicudata at runtime. And for what? To help icu-maintainer keep track of ports, that depend on his own? > this is the way we have always work for library dependency, Not "always". Look inside Mk/ for examples -- shared libraries installed by some frequently-changed ports don't have explicit version requirements already. I don't think, a particular version should be required at all -- unless there is a known good reason for it, such as when the older versions have an important bug or lack a feature needed by the depending port. > Changing this will bring nothing has if icu is bumped sqlite will need > to be bumped because it will be linked to .so.46 which will be away. Yes, PORTREVISION will need bumping (under the current rules). But the dependent ports can still be built on all machines, where libicudata of older (but still perfectly acceptable) version is already installed. Yours, -mi
Hello. Yes, but it was not always so. I checked, during installation port, or creating a package, dependence from the name and version of the library ICU is stored. Despite the fact, that the port itself does not specified of the version. This allows the user to take into account the existing dependencies. On Fri, May 27, 2011 at 22:29, Baptiste Daroussin <bapt@freebsd.org> wrote: > 2011/5/27 Pavel Volkov <pavelivolkov@googlemail.com>: >> Hello. >> Maybe you're right. But, sqlite works equally well when the user has alr= eady >> installed ICU.3 or ICU.4. Depending sqlite in this case does not require= the >> user to update ICU library at the same time upgrading sqlite. >> > =C2=A0There is no more ICU 3 now only icu 4 and the link library is > (currently :) ) libicu.so.46 so if upgrade occurs and sqlite is not > bumped sqlite will just fail. > > Bapt >
State Changed From-To: open->closed This is a non-functional change since a bump in icu's shlib number will require a PORTREVISION bump anyway. There would be no harm in removing the specific version from LIB_DEPENDS at that time, but there is no point in doing it now.
Responsible Changed From-To: freebsd-ports-bugs->dougb I'm closing this one.