On Monday 17 February 2014 20:39:38 Alex Peshkoff wrote: > On 02/17/14 20:27, Adriano dos Santos Fernandes wrote: > > On 17/02/2014 13:08, Dimitry Sibiryakov wrote: > >> 17.02.2014 17:01, Adriano dos Santos Fernandes wrote: > >>> - The data file is common for win32 and win64. If we include the binary > >>> files in our source repository (and I think we should) it's less > >>> megabytes. > >>> > >>> Do you agree with above? > >>> > >> I disagree with including these files into the repository. > >> > >> BTW: Other projects which depend on external packages (such as GTK, > >> for example) used>> > >> to provide two packages: with and without external packages included. > >> This way those who know what they have installed can save traffic. > > > > I estimate a very few number of files summing around 15 MB. > > > > This is much less than current ICU 3 sources, with thousand files > > summing 50 MB and nobody died yet. > > > > What is the problem with you? > > The problem for me is not bytes. I dislike a whole approach called > 'Everything needed for windows build should be present in single > repository'. I think that building firebird anyway requires at lease > minimum qualification (without it - why build at all? use prebuilt > binaries please.) which should be enough to obtain from the net required > additional packages. >
speaking as packager for a small linux distro, I get very upset when I find that a repository has included large chunks from another library, especially as I usually already have more recent versions on my system. Anyone building from source, primarily developers or packagers, should be able to build and install any needed libraries independently of firebird. If packagers wish to include some library in their package, they are free to do so, but this should not be part of the firebird database repository. If the developers wish to maintain separate repositories of upstream libraries, they are free to do so, but should not inflict them on others. The firebird project could include patches which it considers should be applied to certain versions of an upstream library, but it should be the packager's responsibility to apply them. > I can agree when some not ideally supported software (like editline or > btyacc) is added to the repository. But adding to it a library (does not > matter, sources or binaries) well supported by big company is a logical > nonsense on my mind. > > > > ---------------------------------------------------------------------------- > -- Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
