The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Super-Ultra-Mega Build Idea

> If the packaging guidelines had said that debian.rules
> should allow invocation-time redefinition of these vaviables...

This was accidentaly removed from the guidelines, it appears.
It was supposed to be this way initially.

> Regarding stripping executables, I've seen debian.rules files
> which use "install -s" to do that -- which is conceptually pretty
> far removed from "LDFLAGS="...". 

It's trivially easy to switch that on if ( $(findstr -s,$(LDFLAGS)) ) .

> Also, I've seen debian.rules files and upstream package package Makefiles
> with pretty complicated CFLAGS defs -- not something I'd like to type
> in from an invocation command line.

Not all of that stuff should be part of CFLAGS. All of the warning flags,
etc., should be elsewhere. CFLAGS should have optimization, debugging,
and -no-frame-pointer.

> Also, I've seen packages which use different compiler flags to build
> different parts of the package.

This is a problem. Ncurses is one of these.

> Perhaps instead of CFLAGS="...", it'd be better to mandate support of
> "[ ARCH=archname ]", defaulting to i386 if absent

Yes, perhaps.

> and failing the build if
> archname is specified as a value not explicitly supported in debian.rules.

No, why fail the build? That would make adding new architectures very
difficult. Every $CFLAGS can just include "-m$(ARCHITECTURE), and then
new architectures are automaticaly supported.

> Perhaps instead of "LDFLAGS", it'd be better to have "[ STRIP={ YES | NO } ]",

II don't care at all about the STRIP=YES|NO stuff, but the architecture
stuff is important.

> I'd suggest restating the mandate.  Whoever takes this on will be
> re-examining the packaging guidelines and recommending changes to
> support build-time specification of target architecture,
> stripped/unstripped executables,
> (and possibly other matters?).

Let's reduce the scope of this to be only architecture. The unstripped
executables are a bad idea.

	Thanks

	Bruce
--
Pixar Animation Studios: Reality is not our business.
Pixar's "Toy Story", at greater than $184,200,000 in domestic box office
receipts, is the #1 movie released in 1995!