[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: vancouver revisited

> 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 ?


Peter (p2).

Attachment: signature.asc
Description: Digital signature

Reply to: