Le mercredi 25 février 2026, 22:20:09 heure normale d’Europe centrale Sean Whitton a écrit : Hello Helmut, Hello natie, > Hello Helmut, > > Thanks for the updated patch. I have just three remaining changes I'd > like to ask you to make: > > Helmut Grohne [09/Jul 7:14pm +02] wrote: > >> > +- The installed files of a package: Architecture-dependent packages may > >> > + install different sets of files or files with different content for > >> > + multiple architectures and these differences may contribute to the > >> > >> s/multiple/different/ > > > > Yes, thanks. > > Here you did s/different/multiple/ instead. Can you change both > 'multiple's to 'different'? > > >> > In particular, ``postrm`` must consider > >> > + that another instance may still be present. > >> > >> How about: > >> > >> In particular, any ``postrm`` script must not assume that all > >> instances of the package (i.e., instances for other architectures) > >> are all gone. > > > > I don't see what aspect you are improving here and prefer the existing > > wording, because it is more focused on the key aspect. That said, "may" > > is not the right term there. > > I think that "another instance may still be present" is strange. > Up to this point in the text we haven't been using "instance" to mean: > packages of the same name but for different architectures. > Therefore it feels like the reader has to guess that this is what > "instance" means here. My suggested wording avoids that problem. > > >> > +This value should be used rarely for cases where the package can be used > >> > +in an architecture-dependent way or in an architecture-independent way > >> > +and the decision of which applies is deferred to the depender. The most > >> > +common use is with programming language interpreters that enable loading > >> > +architecture-dependent plugins. > >> > >> Can you avoid "should" here? I don't think you intend to be normative. > > > > Unless I misunderstand "should", that particular normative is intended > > here. I was even considering that usage of allowed must be discussed > > with d-devel beforehand just like the use of epochs. > > There seem to be two possible normative requirements: > - if the package can be used in an architecture-dependent way or an > architecture-independent way and it's up to the depender, then you > should use multi-arch:allowed > - you should not use multi-arch:allowed commonly (where common == !rare) > > Are you really trying to say both? I think you really want to say: > - if the package can be used in an arch-dep or arch-indep way and it's > up to the depender then you *can* use multi-arch:allowed > - you should not use multi-arch:allowed commonly > > i.e. just one should. > > If you really do mean both shoulds, then I suggest two sentences/clauses > with "should" appearing twice. But that seems strange because for the > other field values we don't explicitly say that you *should* use this > value if it applies to your package. E.g. we don't say "if the > interfaces the package provides are independent of its architecture you > *should* use multi-arch:foreign". > > Thanks again, just a few changes and then we can second and push this.
Can you get a final review ? >
signature.asc
Description: This is a digitally signed message part.
