I'm not very experienced with rpm packaging. I was hoping Michael would have an opinion on this.
Stuart Children wrote:
a) Is there a reason name, version, and release were being set with %define rather than just setting the tags themselves? The cvs log doesn't offer any clues that I could spot. I can see some people prefering it visibility, but it seems pointless to me. My diff
removes this.
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.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.
c) ftp.enlightenment.org is dead - so I've updated the source URL to point to sourceforge.
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?
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]
[1] On that note, CVS contains a file called "COMPLIANCE". This has the tag-e16_7-pre1 tag but is not in the enlightenment-0.16.7-0.56.tar.gz that's on sourceforge. Should it be? If so then that file also needs to be added to the docs.
I think it should be in the .tar.gz., Will add it. I'm not sure it should be installed though.
E16 will now work in some ugly way even if no themes are installed.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?
g) I've moved %changelog to the end - so that as it grows it doesn't obscure other parts of the spec file.
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.
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.
One other issue - someone can install the enlightenment RPM and not
have a working WM because they don't have a theme installed. I don't
like this very much. My prefered solution would be to create a very lightweight (in terms of size) and visually simple theme, include
this with enlightenment itself, and make it the default theme. Any
artists up for this?
Alternatively from a packaging perspective we could either add the default theme (currently BrushedMetal-Tigert) to the enlightenment package (ie: include both tarballs within the SRPM), or make the enlightenment package depend on the default theme package.
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.
That will do for now. :) Comments welcome. Once I've got feedback on the above then I'll provide patches against the other spec files as appropriate.
I have a session file around that will add enlightenment to the gdm session menu (though this is actually disabled in favour of switchdesk in Fedora at the moment - the "proper" functionality is enabled in RH9 IIRC). I'll post that later too.
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.
/Kim
-------------------------------------------------------
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
