Hey
On Sat, 2004-05-08 at 14:17, Michael Jennings wrote:
> 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. :(
Know the feeling. :(
> > >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?
They are useful for non-developers trying to rebuild from the SRPMs. I
would say that they should match the given configure options - if those
are changed the BuildRequires can be updated.
> 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.
Ah - yes, that makes sense. Hadn't realise that. Thanks for the
heads-up.
> 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.
It's simply a recommendation I've seen elsewhere. Whilst I do agree with
the argument for removing it, I can't say I feel particularly strongly
about it.
> > >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.
OK.
> The _tmppath macro is safe to use. I use it myself.
Good.
> 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.
Fair enough.
> 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.
OK. I'll post new patches (including the other spec files) incorporating
your comments. That should make it easier to review and whoever can
commit them.
> > 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.
Yeah, a virtual provides in all of the themes and a requirement on that
in the enlightenment package itself is probably easiest. Given:
> > E16 will now work in some ugly way even if no themes are installed.
I don't know if it's worth bothering. (Nice one BTW.) I'll provide
patches for this separately.
> > 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.
Definitely include an enlightenment.desktop. This goes in a standard
location and will work on any distro that has a recent gdm (I believe
kdm too actually - but I've never used that). I'll provide a basic one.
People who need to set up Xclients themselves can probably work out what
to do.
I wouldn't bother too much trying to cater for every difference between
distros. It's a fair bit of work, and their own packagers will be doing
it anyway. People who want the best integration should use a package
designed specifically for their system. Distributions will always be
making small changes to spec files - the ideal is that they all have to
change as little as possible from the project supplied one.
Cheers
--
Stuart
-------------------------------------------------------
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
