Re: Antwort: Re: GIMP v1.1.24 RPM Take 2
Alexander Skwar:
No, what I was thinking of, was it would be nice to be able to install a
file in %{_mandir}, and that %{_mandir} would be expanded when the file is
installed. Currently %{_mandir} may expand to /usr/man or /usr/share/man,
depending on the distribution and version/release of RPM installed. Now, if
%{_mandir} wouldn't expand at build time to, say, /usr/share/man,
distributions where man's are still installed in the FHS violating location
of /usr/man would still be fine.
Did this make any sense to you?
it most definitely did, and this behaviour was what i fancied to call a
combination of postinstall-scripts and automake. your proposed macro-
name %{_mandir} would be the convenient interface. how else but with
some sort of automake functionality could it be possible to have packages
built on different hosts to be installed on a host which has already
installed packages with different directory-structures.
we can't even blame anybody, as we might want to install to a variety of
ever-changing places matching the sites evolution. softlinks don't
solve every problem.
clemens
Re: Antwort: Re: GIMP v1.1.24 RPM Take 2
Alexander Skwar: locations? For example, SuSE puts binaries for X in /usr/bin/X11. RPMs I've used to upgrade apps keep putting X binaries in /usr/bin. (Is that the Red Hat standard?) And that's why an install time macro would be so handy. If this would be used, it wouldn't so much matter where the distributor of the RPM places binaries. what do you mean by an install time macro? rpm's, but also tgz and the debian packager specify postinstall-scripts. you want propably a com- bination of this and automake? clemens
Re: Antwort: Re: GIMP v1.1.24 RPM Take 2
On Tue, Aug 08, 2000 at 05:14:45PM +0200, clemensF wrote:
what do you mean by an install time macro? rpm's, but also tgz and the
debian packager specify postinstall-scripts. you want propably a com-
bination of this and automake?
No, what I was thinking of, was it would be nice to be able to install a
file in %{_mandir}, and that %{_mandir} would be expanded when the file is
installed. Currently %{_mandir} may expand to /usr/man or /usr/share/man,
depending on the distribution and version/release of RPM installed. Now, if
%{_mandir} wouldn't expand at build time to, say, /usr/share/man,
distributions where man's are still installed in the FHS violating location
of /usr/man would still be fine.
Did this make any sense to you?
Alexander Skwar
--
Homepage: http://www.digitalprojects.com | http://www.dp.ath.cx
Sichere Mail? Mail an [EMAIL PROTECTED] fuer GnuPG Keys
ICQ:7328191
Antwort: Re: GIMP v1.1.24 RPM Take 2
mdk rpms are specialized RPMs that conform to the Mandrake RPM conventions.
Re: Antwort: Re: GIMP v1.1.24 RPM Take 2
On Mon, Aug 07, 2000 at 11:48:20AM +0100, Alan Buxey [EMAIL PROTECTED] wrote: 'specialised' and 'conventions' spell proprietary in my book. whats wrong with the 'open' RPM standard embraced by the tools already on most Linux, Solaris, Un8X systems? At least according to daniel egger, suse and redhat already use (and need) different specs files for gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Antwort: Re: GIMP v1.1.24 RPM Take 2
hi, mdk rpms are specialized RPMs that conform to the Mandrake RPM conventions. 'specialised' and 'conventions' spell proprietary in my book. whats wrong with the 'open' RPM standard embraced by the tools already on most Linux, Solaris, Un8X systems? best avoid those 'special blands' and keep with the pure. otherwise your only answer is get the tar.gz and then ./configure and make ...and pray alan
Re: Antwort: Re: Antwort: Re: GIMP v1.1.24 RPM Take 2
hi, No, that was not what I meant. Mandrake RPMs are about all compiled with the same settings, use a standard way to update menus for GNOME or KDE and store files like manpages in the same location (/usr/share/man/*). So, if you're using a Mandrake distribution, it is best to stay with Mandrake RPMs to make sure that the package you are using is really optimized in compilation and normal use on Mandrake. ..if you want the bells and whistles (ie nice correlation between menus and icons), sure. if you want revisions that work, then maybe best to move to standard RPMs :-) anyway, i think I've already covered the PERL problem by mentioning 5.6.0 (not sure what RPM flavours that comes in thoughI just get the .tar.gz and compile is from source (far less hassle since I have to place such things on solaris, Unix, Linux, etc) - AND i get to easily choose where they install on the system ;-) ) alan
Re: Antwort: Re: GIMP v1.1.24 RPM Take 2
Am Mon, 07 Aug 2000 schrieben Sie: On Mon, Aug 07, 2000 at 11:48:20AM +0100, Alan Buxey [EMAIL PROTECTED] wrote: 'specialised' and 'conventions' spell proprietary in my book. whats wrong with the 'open' RPM standard embraced by the tools already on most Linux, Solaris, Un8X systems? At least according to daniel egger, suse and redhat already use (and need) different specs files for gimp. That's true, I used to have a redhat and a suse machine and couldn't use the same rpm package. But that's true for quite a lot of rpms. -- mat
