Re: [Cooker] rpm question (provides / conflicts similar packages)
On Wed, 03 Sep 2003 18:35:50 +0200 Buchan Milne [EMAIL PROTECTED] wrote: How should I solve this problem? Provides: samba-client = 3.0.0-0.rc2.2mdk Conflicts: samba-common 2.2.8a-9 If called as urpmi samba-client, urpmi will offer the choice of 3.0.0 or 2.2.8a By same token if any version of samba-common 2.2.8a-9 is on the running system installation of client3 will not be allowed. Charles -- Why are you so hard to ignore? - Mandrake Linux 9.2 on PurpleDragon Kernel-2.4.22-3.tmb.2mdkenterprise http://www.eslrahc.com - pgp0.pgp Description: PGP signature
Re: [Cooker] rpm question (provides / conflicts similar packages)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles A Edwards wrote:
On Wed, 03 Sep 2003 18:35:50 +0200
Buchan Milne [EMAIL PROTECTED] wrote:
How should I solve this problem?
Provides: samba-client = 3.0.0-0.rc2.2mdk
Conflicts: samba-common 2.2.8a-9
If called as urpmi samba-client, urpmi will offer the choice of 3.0.0
or 2.2.8a
By same token if any version of samba-common 2.2.8a-9 is on the
running system installation of client3 will not be allowed.
Hmm, this could work, *if* I tighten the requires on samba-client to =
samba-common-%{version}-%{release} (currently it's only %{version}).
Thanks, I will give it a test, and maybe tomorrow morning we will have a
samba3-client we can actually install (I was testing
update-alternatives, so used --force a bit, so missed this one ...).
But update-alternatives works acceptably now (bonus points for telling
me how to get the most recently installed smbclient to be the best
one, at present smbclient2 is always the best one).
Regards,
Buchan
- --
|--Another happy Mandrake Club member--|
Buchan MilneMechanical Engineer, Network Manager
Cellphone * Work+27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/ViDFrJK6UGDSBKcRAgXeAJ9e6NrOXpMEOcflzxHmj8H9hVIapgCeJ0QJ
n5bcSSBpgFAl3OFBXjsU1+A=
=tLG2
-END PGP SIGNATURE-
*
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy.
*
Re: [Cooker] rpm question (provides / conflicts similar packages)
On Wed, 03 Sep 2003 19:11:34 +0200
Buchan Milne [EMAIL PROTECTED] wrote:
Hmm, this could work, *if* I tighten the requires on samba-client to =
samba-common-%{version}-%{release} (currently it's only %{version}).
Well, you could drop the release from the Conflict if you do not want
any release of 2.2.8a would 'update' to samba3.
As you worded your original you were only concerned if samba-client
2.2.8a-9 was being used.
BTW if the release tag is used urpmi Will update to 3.0.0 anyone running
2.2.8a = 2.2.8a-9
Charles
--
If it's stupid but it works, it isn't stupid
-- Murphy's Military Laws n°36
-
Mandrake Linux 9.2 on PurpleDragon
Kernel-2.4.22-3.tmb.2mdkenterprise http://www.eslrahc.com
-
pgp0.pgp
Description: PGP signature
Re: [Cooker] rpm question (provides / conflicts similar packages)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles A Edwards wrote:
On Wed, 03 Sep 2003 19:11:34 +0200
Buchan Milne [EMAIL PROTECTED] wrote:
Hmm, this could work, *if* I tighten the requires on samba-client to =
samba-common-%{version}-%{release} (currently it's only %{version}).
Well, you could drop the release from the Conflict if you do not want
any release of 2.2.8a would 'update' to samba3.
As you worded your original you were only concerned if samba-client
2.2.8a-9 was being used.
BTW if the release tag is used urpmi Will update to 3.0.0 anyone running
2.2.8a = 2.2.8a-9
Yes, I actually wanted to avoid a Provides: samba-client with version
information, but I think:
Provides: samba-client
Conflicts: samba-common 2.2.8a-9mdk
should do enough of what I want if I tighten the requires on
samba-client (except they could be stuck with a samba-client-2.2.8a-8mdk
and samba-common-2.2.8a-9mdk, unless I conflict samba-client
2.2.8a-9mdk, but then I will end up with a circular conflict back to
samba3-client).
Hmm, will play with this a bit while I fix a few other things.
Maybe I should not worry about the conflicts, it will just cause the
update-alternatives to fail ... (could be worse).
There must be a solution, but the only complete one I can think of
(Epoch) isnt't very attractive ...
Regards,
Buchan
- --
|--Another happy Mandrake Club member--|
Buchan MilneMechanical Engineer, Network Manager
Cellphone * Work+27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/VinCrJK6UGDSBKcRAjQuAKCgxFkY+zQXgrLgpBYlumMItTExZwCaAvGi
aqRXZZESuYiY0QCnJhwUfy0=
=vswd
-END PGP SIGNATURE-
*
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy.
*
Re: [Cooker] rpm question (provides / conflicts similar packages)
On Wed, Sep 03, 2003 at 06:35:50PM +0200, Buchan Milne wrote: So, now assuming: 1)I don't want samba3-client to be installed by default if a user has main and contrib urpmi media and they run 'urpmi samba-client' 2)I want them to be able to choose samba3-client (or install it seperately and not have to keep samba-client-2.2.8a-Xmdk installed to satisfy dependencies on 'samba-client') 3)I don't want anyone with samba-client-2.2.8a-8mdk or earlier to be able to install samba3-client-3.0.0-0.rc2.2mdk or later if built with alternatives support rename samba to samba2? L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media Services S.r.l. /\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \
Re: [Cooker] rpm question (provides / conflicts similar packages)
On Wed, 3 Sep 2003, Luca Berra wrote:
On Wed, Sep 03, 2003 at 06:35:50PM +0200, Buchan Milne wrote:
So, now assuming:
1)I don't want samba3-client to be installed by default if a user has
main and contrib urpmi media and they run 'urpmi samba-client'
2)I want them to be able to choose samba3-client (or install it
seperately and not have to keep samba-client-2.2.8a-Xmdk installed to
satisfy dependencies on 'samba-client')
3)I don't want anyone with samba-client-2.2.8a-8mdk or earlier to be
able to install samba3-client-3.0.0-0.rc2.2mdk or later if built with
alternatives support
rename samba to samba2?
Not an ideal solution, and I would still have to conflicts samba-client
2.2.8a-9mdk, and would probably want to have samba2-client provide
samba-client = %{version}-%{release}.
samba-samba2 has already been implemented, and will take effect when
samba3-samba (samba3 in main) and samba-samba2 (samba2 in contrib).
Regards,
Buchan
--
|Registered Linux User #182071-|
Buchan MilneMechanical Engineer, Network Manager
Cellphone * Work+27 82 472 2231 * +27 21 8828820x121
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
*
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy.
*
Re: [Cooker] rpm question
On Sun, Aug 11, 2002 at 12:57:06PM -0400, Oden Eriksson wrote: Yes, they would conflict... I guess I just leave the package as is. Maybe with a session aware wrapper that does the softlinking depending on what language you feed it with. This is what update-alternatives is for. What I meant here was that the install macro itself would install into a different buildroot or something. And yes we would have conflicting binaries but that's not the point. I just want to know how to do this. You can't have more than one %install package. So it'd be a real pain to do this... At any rate I did another webalizer. This time it makes each language package require the proper locale (the way the rpm howto says to do language specific packages) and uses update-alternatives rather than links done on install... The new version is up here: http://mirror.brain.org/linux/breser/i586/cooker/ -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
Re: [Cooker] rpm question
On lördagen den 10 augusti 2002 14.05 Ben Reser wrote: On Sat, Aug 10, 2002 at 03:28:50PM -0400, Oden Eriksson wrote: This was very simple and strips down the spef file a great deal, I'm impressed!. But..., I think there's a limit of 255 characters that you can have on one line. Aslo it doesn't provide the /usr/bin/webalizer binary for each package, only the softlinks. Quite possible. But if there was some sort of limit I was running into it would error out because the for loop would be closed with a done. However, I do believe the output is limited to 4K that rpm can capture. But for this sort of thing that probably isn't an issue. If the line length ever did become an issue we could move the script into a separate file referenced as a source. Which took params for whatever info it needed (e.g. %lang) and then could be run something like this: %(SOURCE2 %lang) Ok, I will try to look into this later. Thank you very much for the tip. Sure it provides the webalizer binary: [root@occipital i586]# rpm -qpl webalizer-russian-2.01.10-5mdk.i586.rpm /usr/bin/webalizer-russian And after install: [root@occipital i586]# ls -l /usr/bin/weba* lrwxrwxrwx1 root root 17 Aug 10 10:56 /usr/bin/webalizer - webalizer-russian* -rwxr-xr-x1 root root 130904 Aug 9 16:52 /usr/bin/webalizer-english* -rwxr-xr-x1 root root 132632 Aug 9 16:52 /usr/bin/webalizer-russian* lrwxrwxrwx1 root root 17 Aug 10 10:56 /usr/bin/webazolver - webalizer-russian* The only other way to do it is to rename the file to webalizer in the actually package. But then all the languages would have to conflict with each other. Yes, they would conflict... I guess I just leave the package as is. Maybe with a session aware wrapper that does the softlinking depending on what language you feed it with. As I come to think of it we also have another package snort in main that would also benefit from this if we come up with a solution. I could take a look at this... Maybe like this if it was possible: %install -n webalizer-swedish bla bla bla %install -n webalizer-german bla bla bla If this was possible I think we would have found the solution. I'm not sure I follow what you want here. If you mean to package the webalizer-german so it's actually /usr/bin/webalizer well then you run into packages with conflicting files. To me symlinking is the better option. Probably the best thing to do would be to use the update-alternatives system. This would let everyone install more than one language if that's what they wanted but they could switch back and forth. IMHO it's better not to stop people from doing something but to do things in a way that's less restrictive if at all possible. :) What I meant here was that the install macro itself would install into a different buildroot or something. And yes we would have conflicting binaries but that's not the point. I just want to know how to do this. -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
Re: [Cooker] rpm question
On fredagen den 9 augusti 2002 20.01 Ben Reser wrote: On Fri, Aug 09, 2002 at 01:29:02PM -0400, Oden Eriksson wrote: Ok. I have another similar spec file problem... If you (or someone else) have the time, please take a look at the latest webalizer spec file. The webalizer is now providing localized binaries (a whole bunch of them), but in order to make it possible using just *one* spec file I had to rename the built binary as /usr/bin/webalizer-the_lang and do bad woodo magic in %post the_lang. I don't have a clue how to package the /usr/bin/webalizer-the_lang binary as just /usr/bin/webalizer for each generated binary rpm. Do you see the problem? Do you understand what I'm trying to do? I guess It *would* be possible to generate (sub) spec files on-the-fly, and have rpm spawn out and just package these... This is very complicated as you also have to fool rpm itself because you will not have any src.rpm:s for the out-spawned on-the-fly generated stuff... I'm scratching my head here... What you want is the %() construct which runs shell code and the output of it is processed as though it was in your spec file. Unfortunately it all has to go on one line. You could however put the script to do the generation a separate file and list it as a source and call it via %($SOURCE2) but that would require you to also pass it whatever params needed passing... Anyway I've redone it with an inlined script to do the generation. It's kinda ugly but a lot easier to maintain that gobs of separate sections. I've put it up here: http://ben.reser.org/mandrake/x86/webalizer-2.01.10-5mdk.src.rpm Very nice! This was very simple and strips down the spef file a great deal, I'm impressed!. But..., I think there's a limit of 255 characters that you can have on one line. Aslo it doesn't provide the /usr/bin/webalizer binary for each package, only the softlinks. As I come to think of it we also have another package snort in main that would also benefit from this if we come up with a solution. Maybe like this if it was possible: %install -n webalizer-swedish bla bla bla %install -n webalizer-german bla bla bla If this was possible I think we would have found the solution. -- Regards // Oden Eriksson Deserve-IT Networks - http://d-srv.com
Re: [Cooker] rpm question
On Sat, Aug 10, 2002 at 03:28:50PM -0400, Oden Eriksson wrote: This was very simple and strips down the spef file a great deal, I'm impressed!. But..., I think there's a limit of 255 characters that you can have on one line. Aslo it doesn't provide the /usr/bin/webalizer binary for each package, only the softlinks. Quite possible. But if there was some sort of limit I was running into it would error out because the for loop would be closed with a done. However, I do believe the output is limited to 4K that rpm can capture. But for this sort of thing that probably isn't an issue. If the line length ever did become an issue we could move the script into a separate file referenced as a source. Which took params for whatever info it needed (e.g. %lang) and then could be run something like this: %(SOURCE2 %lang) Sure it provides the webalizer binary: [root@occipital i586]# rpm -qpl webalizer-russian-2.01.10-5mdk.i586.rpm /usr/bin/webalizer-russian And after install: [root@occipital i586]# ls -l /usr/bin/weba* lrwxrwxrwx1 root root 17 Aug 10 10:56 /usr/bin/webalizer - webalizer-russian* -rwxr-xr-x1 root root 130904 Aug 9 16:52 /usr/bin/webalizer-english* -rwxr-xr-x1 root root 132632 Aug 9 16:52 /usr/bin/webalizer-russian* lrwxrwxrwx1 root root 17 Aug 10 10:56 /usr/bin/webazolver - webalizer-russian* The only other way to do it is to rename the file to webalizer in the actually package. But then all the languages would have to conflict with each other. As I come to think of it we also have another package snort in main that would also benefit from this if we come up with a solution. I could take a look at this... Maybe like this if it was possible: %install -n webalizer-swedish bla bla bla %install -n webalizer-german bla bla bla If this was possible I think we would have found the solution. I'm not sure I follow what you want here. If you mean to package the webalizer-german so it's actually /usr/bin/webalizer well then you run into packages with conflicting files. To me symlinking is the better option. Probably the best thing to do would be to use the update-alternatives system. This would let everyone install more than one language if that's what they wanted but they could switch back and forth. IMHO it's better not to stop people from doing something but to do things in a way that's less restrictive if at all possible. :) -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
Re: [Cooker] rpm question
Le Vendredi 9 Août 2002 01:29, Oden Eriksson a écrit :
On torsdagen den 8 augusti 2002 11.27 Guillaume Rousse wrote:
Le Jeudi 8 Août 2002 20:12, Oden Eriksson a écrit :
How do I do this ? I have tried %define, but then the whole stuff seems
to have to be on one single line.
Have a look at /usr/share/doc/rpm-%{version}/macros...
Condensed help in this format without examples is useless for non
coders...
Could you give an example?
Unfortunatly not. I've never used such tricks myself, i just now *real*
documentation for rpm is in /usr/share/doc and not in maximum-rpm...
--
Guillaume Rousse [EMAIL PROTECTED]
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] rpm question
On fredagen den 9 augusti 2002 05.07 Guillaume Rousse wrote:
Le Vendredi 9 Août 2002 01:29, Oden Eriksson a écrit :
On torsdagen den 8 augusti 2002 11.27 Guillaume Rousse wrote:
Le Jeudi 8 Août 2002 20:12, Oden Eriksson a écrit :
How do I do this ? I have tried %define, but then the whole stuff
seems to have to be on one single line.
Have a look at /usr/share/doc/rpm-%{version}/macros...
Condensed help in this format without examples is useless for non
coders...
Could you give an example?
Unfortunatly not. I've never used such tricks myself, i just now *real*
documentation for rpm is in /usr/share/doc and not in maximum-rpm...
Ok. I have another similar spec file problem... If you (or someone else) have
the time, please take a look at the latest webalizer spec file. The webalizer
is now providing localized binaries (a whole bunch of them), but in order to
make it possible using just *one* spec file I had to rename the built binary
as /usr/bin/webalizer-the_lang and do bad woodo magic in %post the_lang.
I don't have a clue how to package the /usr/bin/webalizer-the_lang binary as
just /usr/bin/webalizer for each generated binary rpm.
Do you see the problem? Do you understand what I'm trying to do?
I guess It *would* be possible to generate (sub) spec files on-the-fly, and
have rpm spawn out and just package these... This is very complicated as you
also have to fool rpm itself because you will not have any src.rpm:s for the
out-spawned on-the-fly generated stuff... I'm scratching my head here...
--
Regards // Oden Eriksson
Deserve-IT Networks - http://d-srv.com
Re: [Cooker] rpm question
On Fri, Aug 09, 2002 at 01:29:02PM -0400, Oden Eriksson wrote: Ok. I have another similar spec file problem... If you (or someone else) have the time, please take a look at the latest webalizer spec file. The webalizer is now providing localized binaries (a whole bunch of them), but in order to make it possible using just *one* spec file I had to rename the built binary as /usr/bin/webalizer-the_lang and do bad woodo magic in %post the_lang. I don't have a clue how to package the /usr/bin/webalizer-the_lang binary as just /usr/bin/webalizer for each generated binary rpm. Do you see the problem? Do you understand what I'm trying to do? I guess It *would* be possible to generate (sub) spec files on-the-fly, and have rpm spawn out and just package these... This is very complicated as you also have to fool rpm itself because you will not have any src.rpm:s for the out-spawned on-the-fly generated stuff... I'm scratching my head here... What you want is the %() construct which runs shell code and the output of it is processed as though it was in your spec file. Unfortunately it all has to go on one line. You could however put the script to do the generation a separate file and list it as a source and call it via %($SOURCE2) but that would require you to also pass it whatever params needed passing... Anyway I've redone it with an inlined script to do the generation. It's kinda ugly but a lot easier to maintain that gobs of separate sections. I've put it up here: http://ben.reser.org/mandrake/x86/webalizer-2.01.10-5mdk.src.rpm HTH -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
Re: [Cooker] rpm question
On Thu, Aug 08, 2002 at 08:32:21PM -0400, Oden Eriksson wrote: Yes I know, but I want to know how to solve the above stuff. Well the documentation that you've already been pointed to is what you want. Then if want examples look through all the macros in /usr/lib/rpm/ Keep in mind that you can actually put a macro in a separate file: %_post_service uses %_add_service_helper which is just a macro for the: /usr/share/rpm-helper/add-service command... Basically the answer to your question is to read the documentation. But frankly the problem you've presented is already solved so if you don't want to read the documentation, just use what's already there and don't worry about it. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org If your love has no hope of being welcomed do not voice it; for if it be silent it can endure, a guarded flame, within you. - The Wisdom of the Sands
Re: [Cooker] rpm question
On Tue, 2002-07-09 at 09:58, Oden Eriksson wrote: Here's a stupid question once again... Is it possible to do a rpm -Fvh --dryrun somehow to see what-is-about-to-be/could-be upgraded? --test -- Brad Felmey
Re: [Cooker] RPM question...
On Wed, May 29, 2002 at 08:13:44AM +0200, Oden Eriksson wrote: On Wednesday 29 May 2002 06.01, Todd Lyons wrote: But not the check to see if buildroot is set to /. It's not a big issue though since everybody is building as a regular user and not root. Don't take it for granted ;) I seem to recall some packages don't want to build as a user. Can't recall exactly which ones. I'm thinking iptables is one of them... -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org We tend to see all wars through the lens of the current conflict, and we mine history for lessons convenient to the present purpose. - Brian Hayes
Re: [Cooker] RPM question...
Le Mercredi 29 Mai 2002 06:01, Todd Lyons a écrit :
Borsenkow Andrej wrote on Sun, May 26, 2002 at 09:33:41PM +0400 :
I think it would be nice to have:
[ %{buildroot} != / ] rm -rf %{buildroot}
as default in %prep, %install and %clean.
AFAIK it is currently done automatically as part of %setup and it is not
done if you use --short-circuit and it must not be done in this case :-)
But not the check to see if buildroot is set to /. It's not a big issue
though since everybody is building as a regular user and not root.
Even if building as root, i always wondered why the check was only for /. I'm
not even sure it is worst case, as there is no special order in which files
would be deleted, whereas rm -rf /etc would immediatly remove critical files.
--
Guillaume Rousse [EMAIL PROTECTED]
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Re: [Cooker] RPM question...
Borsenkow Andrej wrote on Sun, May 26, 2002 at 09:33:41PM +0400 :
I think it would be nice to have:
[ %{buildroot} != / ] rm -rf %{buildroot}
as default in %prep, %install and %clean.
AFAIK it is currently done automatically as part of %setup and it is not
done if you use --short-circuit and it must not be done in this case :-)
But not the check to see if buildroot is set to /. It's not a big issue
though since everybody is building as a regular user and not root.
Blue skies... Todd
--
Todd Lyons -- MandrakeSoft, Inc. http://www.mandrakesoft.com/
UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things. -- Doug Gwyn
Cooker Version mandrake-release-8.3-0.2mdk Kernel 2.4.18-16mdk
msg65001/pgp0.pgp
Description: PGP signature
Re: [Cooker] RPM question...
On Wednesday 29 May 2002 06.01, Todd Lyons wrote:
Borsenkow Andrej wrote on Sun, May 26, 2002 at 09:33:41PM +0400 :
I think it would be nice to have:
[ %{buildroot} != / ] rm -rf %{buildroot}
as default in %prep, %install and %clean.
AFAIK it is currently done automatically as part of %setup and it is not
done if you use --short-circuit and it must not be done in this case :-)
But not the check to see if buildroot is set to /. It's not a big issue
though since everybody is building as a regular user and not root.
Don't take it for granted ;)
--
Regards // Oden Eriksson
Re: [Cooker] RPM question...
÷ ÷ÓË, 26.05.2002, × 21:04, Oden Eriksson ÎÁÐÉÓÁÌ:
Hi,
I think it would be nice to have:
[ %{buildroot} != / ] rm -rf %{buildroot}
as default in %prep, %install and %clean.
Would that be possible somehow? And if so, how to do it?
AFAIK it is currently done automatically as part of %setup and it is not
done if you use --short-circuit and it must not be done in this case :-)
Which other case do you have in mind?
-andrej
Re: [Cooker] RPM question...
On Sunday 26 May 2002 19.33, Borsenkow Andrej wrote:
÷ ÷ÓË, 26.05.2002, × 21:04, Oden Eriksson ÎÁÐÉÓÁÌ:
Hi,
I think it would be nice to have:
[ %{buildroot} != / ] rm -rf %{buildroot}
as default in %prep, %install and %clean.
Would that be possible somehow? And if so, how to do it?
AFAIK it is currently done automatically as part of %setup and it is not
done if you use --short-circuit and it must not be done in this case :-)
Which other case do you have in mind?
Well, as in %prep, %install and %clean.. I can't seem to find this in the
macro files, or is it somewhere else?.
Most spec files looks like this:
%install
rm -rf %{buildroot}
%clean
rm -rf %{buildroot}
My thought was that you wouldn't have to do that because it would be done
from the %prep, %install and %clean macros as [ %{buildroot} != / ]
rm -rf %{buildroot} instead.
--
Regards // Oden Eriksson
