Bug#27906: PROPOSED] Binary-only NMU's
> Since we cannot rebuild for all architectures simultaneously and do
> not want to withdraw binaries or wait with porting,
> *we MUST be able to have more than one source version in our archive*.
[...]
> i. Simply have them side by side, with some kind of way of making
> obsolete sources disappear eventually
> ii. Some arrangement with .nmu files
>
> It seems to me that (ii) will be slow to design and implement. We
> must therefore implement (i) immediately.
Basically it's ok for me to have multiple source version on out FTP
server. But please keep in mind the following points:
- This will increase the size of the source archive by maybe 100 MB
(roughly 3 or 4 .diff.gz and .dsc files per package then; all
estimation!) Ok, no real problem...
- There should be an easy way to find the newest source version. For
a human this is a rather easy task if they're side-by-side, but
humans can make errors. It's also more convenient if the newest
version could be more directly accessed than others. And there are
some scripts (for us recompilers) that go through the source
archive and collect the versions. It should be possible that such
scripts still work or can be easily adapated.
- If there are multiple source version, the question also arises
which one should be considered the newest one... If there's
foo_1.0-1 and I make a NMU foo_1.0-1.1, which fixes a m68k-only
problem, the latter is surely the newest one for m68k. But for
i386, alpha, sparc, ...? They don't need the fix I've done in -1.1,
so they don't need to recompile. Maybe a human can see this from
the changelog, but how to do it automatically?
Roman
Reply to: