On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote: > It's my opinion that same version uploads to stable/unstable are harful > to archive and distribution integrity.
There is a deep reason why this makes sense, but I think you didn't mention it explicitely. The reasons you mentioned are practical, but not critical. The critique is justified, because if it *does* matter if you compile on stable or unstable it should not say "stable unstable" in the changelog. (In practice, the set of such package is small for the reasons you mentioned rightfully). IMHO, the fundamental and unavoidable reason why we have this problem is the following: We don't know in which Packages files (=distributions) a single binary is (used or) going to be used. This is a source for conflicts and inconsistencies, because whenever you want to compile something you have to make sure it will be okay for all distributions it is going to be used in. As this includes decisions made in the future[1], there are potential problems you can't address. The testing area faces this problem as well. It was solved partially by deciding that a package only enters the testing distributions if it was available on all to-be-released architectures. This provides some amount of consistency: You knew that the same version of a package was used in all released architectures (not too unimportant if you consider binary-all packages). This partially addresses the cross-architecture problem. The orthogonal problem is not solved: cross-releases. We had no solution for this in the past[1], we don't have a solution for this, and your proposal solves this by eliminating "merged parts of the branches". After the release, we split off and keep updates distinct. It is a rough decision, but it is workable. To solve the generic problem, we would need an entirely different mechanism to keep track of distributions a package currently belongs to and develop various strategies what to do with packages belonging to various groups. (You mentioned some, like compiling for stable and uploading to both). It is really an interesting problem, but too hard to solve in its generality, I am afraid [2]. Restricting the possible cases with proposals like yours is very reasonable. In fact, what you propose has the effect of seperating the source archives for unstable and stable (without duplicating identical sources). It's like a split off of the pool at release time (but without performing the actual split physically). Semantically, it seems to be the right thing to do. I think I support your proposal, but I haven't read the exact wording very thoroughly yet. Thanks, Marcus [1] You can upload to stable and unstable, but you don't know if it will really be accepted for stable. You can upload to unstable, and you don't know if or when it will reach testing. [2] I have not thought this through. I have thought about it a bit, and the amount of possible cases is stunning. In fact, potentially unlimited. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
