I sent this proposal to f-m-l about a week ago to gather comments, and
there were no serious disagreements with the proposal which have not yet
been addressed (thanks to Tibbs and Toshio for their feedback).
Basically, I want to establish a set of guidelines for packaging Tcl
extensions, as we already have guidelines for other popular scripting
languages. In addition to making Tcl packages more consistent with each
other, it will also help work toward fixing my pet-peeve bug (bz #226893)
Please let me know if I need to do anything to help get these draft
- don't worry about group
- tweak license wording
- use <blah>-firmware naming
Here's the updated firmware packaging proposal. Comments? Can we get this
approved - there are packages that meet the existing firmware guidelines
that are waiting on packging guidelines for approval.
Any opinions on %config files in /usr? This seems to violate all
sorts of common sense surrounding shared or read only /usr, but does
not seem to be mentioned in the guidelines.
An example package is hwdata:
Patrice mentions in that bug that FHS covers us here, but the
guideline only asks that deviations from FHS be rationalized.
So we voted on a new *mandatory* buildroot. By now people saw that the
previous *mandatory* buildroot entered the guidelines and started
blocking new packages requiring the old *mandatory* buildroot.
I don't know what fesco did last week on ratifying or not the new
buildroot, and either way people will think differently on any single
buildroot. Perhaps buildroots are the most unimportant piece of s**t
with the most polarized parties.
Now who's idea was it to have a *MANDATORY* buildroot at all?</rhetoric>
Most of the FPC are fed up and have often stated that the buildroot
guidelines should be simple "If it works, have it".
Plain and simple:
Request for voting on dropping the *mandatory* from the guidelines
and explicitely cast it into a *suggestion*
The first other five positive voters get a free beer when I meet
them (we never said that committee members could not be bribed, or do
we need a guideline for that? ;)
Axel.Thimm at ATrpms.net
I've blocked a submitted package (ntop) on FE-Legal. I'm not sure who
to prod regarding "Apache License, Version 2.0, incompatible with GPL"
starting at comment 46.
If this is going to be a problem, it looks like I can remove the Apache
2 files (patch them out). I'm assuming that is sufficient and a
modified tarball won't be needed.
used by the built-in web server.
Can someone who does the FE-Legal reviews take a look at this for me?
Just a minor edit to the previous proposal.
I'd like the firmware section of the packaging guidelines modified
1) Firmware packages are given the Group: tag of Firmware
2) The License tag for any firmware that disallows modification should
be set to:
"Redistributable firmware, no modification permitted"
I'd write something for the PackagingDrafts, but it's locked down.
Can we get this approved?
Thanks in advance,
For some time I've been working under the assumption that executable
documentation is a bad idea. rpmlint complains when documentation
generates dependencies, and these dependencies are often needless
Lately I'm getting pushback when asking for a quick chmod -x of docs.
The usual argument is "It's an example, it's supposed to be
executable." Currently I don't see anything in the guidelines that
would forbid this as long as it doesn't cause extra dependencies.
So, is there concensus that allowing documentation to be executable is
OK? Or is it something that should be prohibited.
a) the raguments were mainly between racor and myself
b) topic was decided on an IRC meeting I couldn't attend
c) The summary of my arguments were given by ... racor ???
d) My arguments were not "I do it with macros, don't care about the rest"
=> Deliberately misquoted?
e) True arguments are that
obscuring the buildroot for the sake of an extremely rare
corner case (several users building the same package on the
same system w/o chroots) implies fixing it for far more not
corner-cases like building i386 and x86_64 packages
simulataneously. So the `id -nu` part is far less important
than adding the target arch, but that was silently forgotten by
I remember us waiting for racor to finish with his relocation for a
couple of months before dicussing topics where he was having an
active opinion and in this case it's a blitz decision in absence of
one party. I'm also not amuised by racor's misquoting, be it
deliberate or not.
In light of the above I'd like to ask to rediscuss this.
Axel.Thimm at ATrpms.net