On Saturday, 08 May 2004, at 10:19:24 (+0200),
Kim Woelders wrote:
> I'm not very experienced with rpm packaging. I was hoping Michael
> would have an opinion on this.
Sorry, I've been super busy. I've only been able to skim e-mails, and
I seem to have missed this one. :(
> OK, It seems that "Version: <xyz>" makes "%{version}" be defined to
> "<xyz>". I wasn't aware of that. I was just trying to avoid having to
> make the same change in more than one place.
Yes, %{name}, %{version}, and %{release} are generated by RPM itself
and need not be defined by hand. While doing so is technically
harmless, it's also redundant and unclean.
> >b) I've removed the Packager tag. It's not a good idea to have this
> >in the CVS version as people might download e and create their own
> >packages with that information in there - which may lead to confusion
> >(obviously if they want to do this deliberately you can't stop them,
> >though signing packages helps). People actually creating packages
> >should set this tag in their ~/.rpmmacros.
True. I've been using the following value in my more recent packages:
%{?_packager:%{_packager}}%{!?_packager:%{_vendor}}
> >d) I've added required build dependencies.
> >
> Are they useful? They are incomplete and incorrect, particularly if the
> configure options are changed. Or should the configure options be
> considered fixed within a spec file?
This is a no-no. BuildRequires should only be used by individual
distributions due to package naming differences. If specified via
files, however, that might be okay. Just not package names.
> >e) I've stopped the INSTALL file being installed with the other docs
> >- it's a bit pointless for people using binary RPMs. Those who do
> >want to see that information can look at the SRPM which obviously
> >contains it in the original tarball. I've made the ChangeLog file be
> >installed. [1]
Many, many packages have INSTALL files that are not needed for users
of binary RPM's. However, they are still installed for reference. I
see no significant problem with installing it, nor can I come up with
a strong reason not to. So I'd recommend leaving it in.
> >f) I've removed the Docroot tag. I don't think it's needed, but it's
> > possible that it's there for some other distro/old rpm version - can
> > anyone confirm?
No, it's not needed. It's been awhile since e.spec has had a thorough
house-cleaning.
> >g) I've moved %changelog to the end - so that as it grows it doesn't
> > obscure other parts of the spec file.
I do that too. :)
> >h) I've changed BuildRoot to use %{_tmppath} and %(%{__id_u} -n) -
> >the latter prints out your username. This is a recommendation in the
> > packaging guidelines for fedora.us. However, I'm not sure whether
> >all distros have the _tmppath macro, or which versions of rpm support
> >the latter bit. So I'd appreciate it if anyone can point out any
> >distributions this fails on. My version allows packages to specify
> >where packages get built (ie: it doesn't have to be /tmp) and adds
> >protection against clashes simultaneously building different releases
> >of the same package.
The _tmppath macro is safe to use. I use it myself. However, I
recommend against the %(%{__id_u} -n) part. If you encounter clashes
while building packages, this is an indicator that you're building in
an unsafe environment and should, at the very least, point %{_tmppath}
to a different location ($HOME/tmp for instance). Packages should
never be built in an uncontrolled environment, so adding ways to
circumvent the big red flags that pop up seems counterproductive to
me.
> >I hope that all makes sense. Please feel free to reject any parts of
> >the changes. Some of these things may well be deemed too specific and
> >I don't mind keeping them in a custom spec file. However, if they are
> >of general benefit then they should go back into CVS.
> >
> >If you want to be very cautious about anything which may stop this
> >compiling on old rpms etc, then I would nominate f) and h) as being
> >the risky parts. However, unless anyone objects then I'd say make the
> > changes and if problems are discovered later they can easily be
> >fixed. It would only be an issue for people who are compiling RPMs
> >themselves.
Except as stated above, your changes seem reasonable. I'm
unfortunately too swamped to commit them myself, but hopefully someone
else will (as modified above), and I'll watch the CVS e-mail to make
sure it was done okay.
> With rpm's, isn't it possible to require just any theme? I'd
> *really* like to keep the themes separate from the code. I think
> that is how things should be.
It's possible but tricky. That's why some type of default is usually
built into the package. Barring that, though, it's possible to do
something either with pseudo-Provides tags or adding a Requires: line
for /usr/share/enlightenment/themes/DEFAULT and some triggers in the
themes to make it happen.
> I think that it would be nice if the rpm could install on just about
> any distribution. So I have been considering somethink like
> including the files Xclients.e16, Xclients.e-gnome, Xclients.e-kde,
> e16.desktop, e-gnome.desktop, and e-kde.desktop somewhere
> (<docdir>/something?) and making a postinstall script copy them to
> the appropriate locations depending on distribution/version.
The problem with doing it in %post is that you can't take action when
foreign packages are installed/removed. For example, let's say
someone happens to switch from GNOME to KDE after installing E. You'd
need to switch Xclients files, most likely. I think the answer here
would again be triggers unless all files could be installed
simultaneously.
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"If you obey all the rules, you miss all the fun."
-- Katherine Hepburn
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
