> > I don't agree with that interpretation of "arch-specific", and neither > do the maintainers of the Packages-arch-specific list AFAICT, so please > stop trying to use creative interpretations of people's words to torpedo > the proposal that porters should be accountable for their ports. >
I have no idea what you're trying to say here. > > > > and it cannot be the porters problem that packages violate > > > > language rules and therefore fail to compile or work on some arch. > > > > well, if the package is bogus from the language usage, than that's not > > > the porters problem (but how often did that hit exactly one arch?). If > > > the arch can't e.g. use C++-packages because it doesn't have the > > > toolchain for c++, I think that is the porters problem (just to give an > > > possible example). > > > I have seen multiple examples of builds failing because the testsuite or > > a buildtime generated tool crashed on a specific arch due to bad coding > > practices. > > And in some cases these are so severe that the package should > unequivocally be ignored for that architecture. In other cases, it is > incumbent upon porters to, y'know, *port*. If we're going to give a > port a free pass every time some base package, or package that's > installed as part of the desktop task (for example) manages to include > code that's not portable, then I don't see any point at all in treating > these as release architectures to begin with, because at that point > they're *not* shipping the same OS that the other architectures are. > What did you want to say here ? Cheers, Peter (p2).
signature.asc
Description: Digital signature
