Tcl packaging guidelines proposal
by Michael Thomas
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)
http://fedoraproject.org/wiki/PackagingDrafts/Tcl
Please let me know if I need to do anything to help get these draft
guidelines adopted.
Thanks,
--Wart
16 years, 3 months
Firmware packaging, v3
by Bill Nottingham
Changes:
- 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.
Bill
17 years, 2 months
Configuration files in /usr
by Jason L Tibbitts III
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:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225893
Patrice mentions in that bug that FHS covers us here, but the
guideline only asks that deviations from FHS be rationalized.
- J<
17 years, 2 months
Stopping the mandatory buildroot insanity
by Axel Thimm
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*
+1
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
17 years, 2 months
FE-Legal review
by Bernard Johnson
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.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219025#c46
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.
Since someone will ask: No, this is not documentation, it is javascript
used by the built-in web server.
Can someone who does the FE-Legal reviews take a look at this for me?
Thanks.
17 years, 2 months
Firmware packaging, v2
by Bill Nottingham
Just a minor edit to the previous proposal.
I'd like the firmware section of the packaging guidelines modified
to add:
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,
Bill
17 years, 2 months
Executable documentation
by Jason L Tibbitts III
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
bloat.
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.
- J<
17 years, 2 months
Wrong buildroot ...
by Axel Thimm
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
racor
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
17 years, 2 months
