Re: two OOo orig.tar.gzs?
On Wed, Mar 01, 2006 at 12:48:34PM +0100, Matthias Klose wrote:
> Jeroen van Wolffelaar writes:
> > Hm, duplicate sources seem like quite a hack to me,
>
> really? for other sources they were requested by the release
> team. or do you mean "it depends ..."
Yeah, it depends definitely. I'm not well familiar with OO.o packaging,
so I cannot give a very informed opinion, and cannot help it to be
pretty much from ftpmaster perspective lacking any adequate OO.o
perspective.
> > and a potentially fragile at that.
>
> 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?
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.
> > The bottom line seems to be that OO.o has insane disk and build-time
> > requirements. Assuming those themselves cannot be resolved
> > significantly, and realizing that the very-long build-time is mostly due
> > to the help stuff that's arch:all, and thus not involving buildds, I
>
> so you propose and advise on hacks like "if user == buildd" in
> the build scripts.
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.
The real fix would be to get the buildd's sbuild to do 'build-arch'
(with fallback to 'build' in case exitcode is 2). Or some alternative
solution, one was tried (and backed out) in 2003 (using make -pn or so).
I have initiated discussion about this, and will followup. Pending
resultion, please use the above-suggested 'hack' instead of
user==buildd. It is still completely according to policy, the
distinction between binary and build is a bit fuzzy anyway -- it's
indeed against the spirit of that distinction though, but it doesn't
really matter much in practice. Also read in policy:
| 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').
> > think the sources should not be split, and simply good care should be
> > taken to ensure there will be no gratuitous OO.o uploads, to reduce
> > burden on mirrors.
> >
> > I'd really like to urge the OO.o team to look into reducing these
> > requirements fundamentally though.
>
> You know what you are asking for? The strings in the help are managed
> in the same way as every other message. So you either ask to change
> the upstream l10n framework, or to reduce the sources needed to build
> the help. Urging for the former seems interesting, doing the latter is
> the thing I call "potentially fragile" (dropping a 35MB tarball seems
> doable though).
No, I don't know what I'm asking for will involve precisely, because I'm
not familiar with OO.o. I'll trust on your judgement on the matter, if
you think it isn't feaseable, well, then it isn't feaseable. Since I'm
not volunteering to rework upstream's l10n framework, and I assume
nobody else is (yet), we'll all need to go with what there is.
> 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
isn't completely required? If the extra source waste is significantly
less than 200M, then I guess such a source package split is certainly
worth considering anyway. From a perspective of
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: