On Fri, Nov 23, 2012 at 02:22:25PM +0000, Wookey wrote: > +++ Colin Watson [2012-11-23 13:31 +0000]: > > Do you have an opinion on this part? If not, I think my default would > > be for the next version of this patch to move autosprintf.info.gz back > > to gettext, for safety. > > Doesn't this problem of potentially-rebuilt text/doc/info files exist > all over the place?
Not that widely. The bulk of documentation in M-A: same packages, as far as I've seen so far, is just static files, which are just fine. > I've come across it in perl docs which embed the build date, not the > doc-creation date, for example. Those clearly must not be in M-A: same packages because they will rarely if ever manage to be identical. That's a different issue from cases like this, which will generally be identical across architectures but where we might occasionally be unlucky. > Essentially any doc in an M-A same package has the issue of rebuilds > potentially changing the text. i.e. there is nothing special about > gettext here. Is texinfo version skew likely enough to break things > that we should worry. I don't like leaving timebombs around behind me. It seems like the kind of thing that my future self would be likely to curse me for doing. > One way of dealing with this is moving all docs out of M-A: same > packages, and docs are arch-independent stuff so it makes some sense. That would be drastic overkill, since many documentation files are obviously invariant across architectures. We already have a clear rule that says that things that vary across architectures must not be in M-A: same packages. This is only a difficult situation because it will only vary if we get unlucky (although it's a predictable kind of bad luck, rather than cosmic rays); but we don't need to generalise the problem further than necessary. > What we really want is QA checks on MA co-installability and > corresponding rebuilds/fixes where it's gone wrong. We should certainly have this, but I don't think it absolves us from trying to insure against predictable problems up-front. -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
