Hi, Jeroen van Wolffelaar wrote: > > > > care to explain, in which way? > > I don't know for sure of course, but what if the help gets out of sync > with the binaries? What will happen when you have help that doesn't > match the binaries of OO.o, and especially, having help that was build > >from a different package than the binaries?
Then you watch whether updates to patches affect help/l10n or not and whether that's important. And update the others source too if you need to do.... If not, fine. > I note that the current situation is exactly this, so I guess/assume the > risk of fragileness I suspected isn't a significant one or maybe doesn't > exist at all. There may be some occurances, but they should be pretty rare. Also note that the current -help in contrib does that already as you notices - but without *any* sync to patches done vs,. the "normal" openoffice.org or sync with the translation updates we apply to the "normal" openoffice.org. So that's more risk :) > Some packages do this by having 'build' not depend on 'build-indep', and > having 'binary-indep' depend on 'build-indep'. This will cause the > build-indep to be run under (fake)root, but it works -- and to the best > of my knowledge, there are more packages doing so. That doesn't really help in any case or I oversee something. Since the l10n and help build is so tighly coupled with OOo... > user==buildd. It is still completely according to policy, the user==buildd is already theer since ages to build only the english langpacks on the buildds (help not built). Otherwise we would have even longer build times on the buildds than we have now, without the long Help build (which indidentially improved a bit by making the HelpLinker a native binary but it's still not fast...) > | For some packages, notably ones where the same source tree is compiled > | in different ways to produce two binary packages, the build target does > | not make much sense. For these packages it is good enough to provide two > | (or more) targets (build-a and build-b or whatever) for each of the ways > | of building the package, and a build target that does nothing. The > | binary target will have to build the package in each of the possible > | ways and make the binary package out of each. > > This is actually a very similar situation, and hence already somewhat > covered in policy (though the 'different ways' here are actually > 'different parts to be compiled'). Not really. Most part is identical. You can strip down the sources needed for help build, yes, but not for the l10ns. For the l10ns you really need to build the full Office anyway, but what the output is is arch-independent. Yes, we probably could do a build-* split (all langs when built with build-indep and only english when -arch, but that still doesn't say anything about the upload and mirror hit size you would have). You still would need upload all l10ns and all helps when you do a normal binary + source upload as maintainer. > > Your arguments make sense from the perspective as ftpmaster, but don't > > help the debian developers. So maybe just keep the > > ooo-helpcontent source package, as it's currently done? > > Ren? said that also for the help, full sourceball was needed. So this For l10n it is. For help not. But I already only proposed two (binaries + -help-en-us + -l10n-en-us) + -l10n instead of three (binaries+l10n-en-us + l10n + help) which would have the opportunity to strip something off the source (see contrib atm which has a openoffice.org-help which had to be because the help wassn't yet buildable with free Java) > worth considering anyway. From a perspective of Something missing? Regards, Rene
signature.asc
Description: Digital signature
