Request to drop %(%{__id_u} -n) in preferred buildroot
by Axel Thimm
Hi,
I think the `preferred buildroot' is not really making sense. The
above has developed historically out of a misunderstanding in ancient
buildroot times.
When people were building as root and BuildRoots were defined as
%{_tmppath}/%{name}-%{version}-root, some considered "root" to mean
the uid of the builder. Later %release was added and some replaced
root with `id -un`. Even later some realized that root was referring
to the BuildRoot and in order to play safe added both.
I'm using %{_tmppath}/%{name}-%{version}-%{release}-root in my
packages and someone is now nitpicking on why not using the preferred
BuildRoot as given in the guidelines. Instead of locally fighting a
BuildRoot battle, I'd better get the guidelines fixed ;)
Also consider what this really is about: Deambiguifying the BuildRoot
per package makes sense as there may be several build processes
sharing the same filesystem (either locally or through NFS), but
deambiguifying the build user, too, means that we assume that the same
EVR package will be possibly built on the same filesystem by
different users? And even simultaneously?
It makes more sense to include a conditional epoch or target/arch in
the buildroot that the builder. In fact the best thing for a
buildsystem is to override the buildroot adding a build-id to it
anyway.
--
Axel.Thimm at ATrpms.net
16 years, 5 months
--vendor fedora, rationale/motivation?
by Rex Dieter
Per
http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines:
The vendor prefix (desktop-file-install --vendor=...) must be set to
fedora".
I don't understand the rationale/motivation behind requiring '--vendor
fedora'
I can, however, see that desktop-file-install's current
implementation(*) of prepending %{vendor}- to the .desktop file name has
some problems/issues:
1. .desktop filename now varies from upstream
2. --vendor may change when/if Extras bits are pulled into Core and/or
RHEL.
3. *In particular*: when users start employing menu editors, since
most(all?) of them base their customizations on the .desktop file name.
-- Rex
(*) If desktop-file-install's implementation instead followed something
like kde's practice of using a vendor directory (e.g.
/usr/share/applications/kde), then (1) and (3) would no longer be an issue.
16 years, 6 months
Importance of debuginfo packages
by Jason L Tibbitts III
Often when doing package reviews I find a package that needs some hack
in order to get rpmbuild to build a complete debuginfo package. Some
of this relates to passing the proper compiler flags and making sure
the package doesn't strip its own binaries, which I think is
necessary, but occasionally rpmbuild needs the source to be moved
around in the build tree, or it needs symlinks flattened or somesuch.
These are just hacks to work around rpmbuild deficiencies, and I can
understand if packagers are reticent to clutter up their packages for
something of unknown value. So, how important is it to have a proper
debuginfo package? How much hacking is permissible or necessary in
order to achieve that goal? Is an incomplete debuginfo package (that
contains, say, the striped debug information but is missing some or
all of the source code) still useful, or would it be better to have
none at all?
- J<
16 years, 8 months
cmake best practices
by Orion Poplawski
It appears that more and more projects are moving to cmake, especially
with KDE4 making the jump. Two packages of mine (plplot and kdesvn) are
also making the switch. I also happen to be the current packager for
cmake itself (because I package paraview which uses it), though I expect
it will have to get moved to core relatively soon.
It seems like it is time to start collecting cmake best practices for
generating Fedora RPMS using cmake, and perhaps even creating a %cmake
rpm macro that is analagous to the %configure macro.
Here's what I have so far (note that cmake generally does out of tree
builds):
%build
mkdir fedora
cd fedora
export CFLAGS="$RPM_OPT_FLAGS"
export CXXFLAGS="$RPM_OPT_FLAGS"
cmake .. \
-DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \
-DBUILD_SHARED_LIBS:BOOL=ON \
-DCMAKE_SKIP_RPATH:BOOL=ON
make VERBOSE=1 %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
cd fedora
make install DESTDIR=$RPM_BUILD_ROOT
I'm also running into trouble getting kdesvn to install into /usr/lib64
on x86_64. This might just be a matter of educating upstream users on
the proper cmake commands for this (once I figure that out myself...).
Currently there is lots of hard coding of "lib" into install paths.
Now, where to put this in the wiki?
--
Orion Poplawski
System Administrator 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
16 years, 9 months
Re: RFC: Creating meta group packages via comps
by Jeremy Katz
On Tue, 2006-08-29 at 11:09 -0700, Christopher Stone wrote:
> It should be really easy to make a script that builds metagroup
> packages from comps, no?
>
> This will allow someone to install a group such as kde/gnome as an rpm
> package and when packages are removed/added/changed in the comps
> groups, the meta group package also changes, and the user gets the
> appropriate changes.
>
> I don't think this is possible now with the groupinstall feature in
> yum which IMO is a bad feature since it should be done with meta group
> packages as I describe.
>
> Comments?
The entire point here is that there don't have to be packages to keep
track of this metadata -- so if you change comps, you don't have to go
change lots of packages. This is also really helpful for doing
site-specific customizations of what the various groups are.
The argument about a "noob" is pretty much moot as they're far more
likely to be using the graphical interface as opposed to yum on the
command line. And at that point, the comps file becomes even _more_
important as it's used for the entirety of the display.
Jeremy
16 years, 9 months
RFC: Creating meta group packages via comps
by Christopher Stone
Hi,
It should be really easy to make a script that builds metagroup
packages from comps, no?
This will allow someone to install a group such as kde/gnome as an rpm
package and when packages are removed/added/changed in the comps
groups, the meta group package also changes, and the user gets the
appropriate changes.
I don't think this is possible now with the groupinstall feature in
yum which IMO is a bad feature since it should be done with meta group
packages as I describe.
Comments?
16 years, 9 months
New Meeting Time
by Toshio Kuratomi
Hi guys, as discussed in the meetings for the past couple of weeks,
we're trying to change the meeting time. I've started a wiki page with
a simple calendar to fill in days and times that work for you. You can
also block off a section of time that doesn't work (as I've done for the
West Coast sleep & commute period).
http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime
-Toshio
16 years, 9 months
Best practise license checking?
by Till Maas
Hiyas,
do you have any recommendations on how to check which license a package uses?
Is it enough to look at the upstream homepage or README which license it uses
or need a reviewer perform a code inspection? In the latter case is it enough
to check the headers of each file for licensing? And has each file have a
header with an allowed license? And after review, has the maintainer to check
on each new file on each release whether or not the file has an allowed
license?
Regards,
Till
16 years, 9 months
