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

Re: architecture wildcards, type-handling, etc.



Hello Salvatore,

On Thu, 14 May 2009 19:25:46 +0200, Salvatore Bonaccorso wrote:
> Dear reader of debian-mentors,
> 
> I read the following, following a discussion on debian-devel, which I
> do not understand.
> 
> On Thu, May 14, 2009 at 04:26:56PM +0200, Cyril Brulebois wrote:
> > brian m. carlson <sandals@crustytoothpaste.ath.cx> (14/05/2009):
> > > I've worked on FTBFS-with-new-GCC bugs before, and realized only after
> > > putting significant work into the bug that the package didn't build on
> > > amd64, only on i386.  Therefore, I think that the package should have
> > > a proper list of archs that prevents this problem.  P-a-s is fine for
> > > the buildds, but if you actually want people to volunteer to fix bugs
> > > on your package, you shouldn't make it harder on them.
> > 
> > Which is why people are expected to:
> >  - Make their packages FTBFS ASAP in the build system, to make it
> >    obvious it's not intended to even be tried on $archs.
> >  - Then get the P-a-s entry added.
> 
> Could that a bit be explainend? I do not understand the following:
> Assuming I have a package, which I know it is only working under i386
> and amd64, but has the "bug" that it builds correctly on another
> architecture (but is then not usable there), does this mean, that I
> should not put only i386 and amd64 in "Architecture" field, but
> instead nevertheless let "any" by in the Architechture field, but then
> on build time, let the build fail on say powerpc?
> 
> Many thanks
> Salvatore
> 
> btw, what "p-a-s" mean in this context?

p-a-s : dict say "Publicly Available Specifications (ISO)"
I think this is the correct signification but i am not sure...

For your main question, i am not sure but in Debian policy i remember that a
FTBFS has to be forward to the upstream project (with or not a patch) and has
to be integrated in the next version of the upstream package or stay in
specific Debian patch (not the best solution). If upstream doesn't want to
support other architecture (i don't see why ?), i think the two solutions are
good technically, but only one is good according to Debian project goals :
any...

May be i am wrong and i am just a beginner in Debian, so advanced Debian
programmers can take place and have another opinion on the problem.

Best regards,
Laurent.

-- 
Laurent Guignard, Registered as user #301590 with the Linux Counter
Site : http://www.famille-guignard.org
Blog : http://blog.famille-guignard.org
Projet : http://sicontact.sourceforge.net
GULL de Villefranche sur Saône : http://www.cagull.org

Attachment: signature.asc
Description: Digital signature


Reply to: