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
15 years, 9 months
Missing most meetings until mid-September
by Axel Thimm
Hi,
I'm quite busy in August [no, not with a vacation ... :/], so I will have
to skip most meetings. Please ping me when my vote is needed (although
most voting are almost unanimous, so my vote will not be
neccessary). I'll try to look into the meetings whenever possible.
--
Axel.Thimm at ATrpms.net
16 years, 2 months
Users and groups -- the static alternative
by Toshio Kuratomi
The Packaging committee has been discussing users and groups for a long
time, coming up with increasingly elaborate methods of solving the
problems with dynamic allocation of uids.
As an alternative we want to explore biting the bullet and just
allocating another uid range for static assignment.
We thought of two possible ways to do this that made some sense:
1) Allocate the uids at the high end of the 32 bit range: 2**32-(range)
to avoid the uids being used on as many systems as possible.
2) Work with another distro to share the range of static uids.
What do people think of this? Will it cause pain for too many sites?
Is it an acceptable cost to avoid having to debate dynamic vs static
uids for every package review in the future?
-Toshio
16 years, 2 months
Make empty debuginfo packages a build error?
by Ville Skyttä
Hi,
How about making empty debuginfo packages a build error? I can't think of a
reason why an empty one would be a desired result, but empty ones do almost
always indicate problems with the build. Arch specific packages that
expectedly don't have anything to place into the debuginfo package should
explicitly disable it eg. with "%define debug_package %{nil}".
Also submitted as https://bugzilla.redhat.com/249956
16 years, 2 months
rpmlint check for proper %defattr?
by Jason L Tibbitts III
I'm seeing a lot of reviews lately with complaints about %defattr. I
admit to not always checking it myself, but this seems to be the kind
of thing that rpmlint could easily check for.
I know that the complete lack of %defattr is problematic, but I'm not
sure whether "%defattr(-,root,root)" is a blocker or not. The only
place it seems to be mentioned is in %lang section of the guidelines
(and in templates contained in the various language-specific
guidelines).
- J<
16 years, 2 months
