| View previous topic :: View next topic |
| Author |
Message |
Astroman
n00b
Joined: 03 Sep 2002
Posts: 6
Location: Germany
|
 Posted: Tue Sep 03, 2002 11:13 am Post subject: emerge overwrites packages.mask |
 |
|
Whenever calling emerge rsync, the packages.mask file is overwritten which discards any changes I have done to it.
Is there a way of constantly masking/unmasking ebuilds? 'cause manually editting packages.mask everytime I emerge rsync can't be it. |
|
| Back to top |
|
 |
kirill
Apprentice
Joined: 01 Aug 2002
Posts: 183
Location: Finland
|
| Posted: Tue Sep 03, 2002 11:21 am Post subject: Re: emerge overwrites packages.mask |
|
|
| Astroman wrote: | Whenever calling emerge rsync, the packages.mask file is overwritten which discards any changes I have done to it.
Is there a way of constantly masking/unmasking ebuilds? 'cause manually editting packages.mask everytime I emerge rsync can't be it. |
I don't know if it will work for unmasking but you should be able to mask stuff using your own packages.mask in $PORTDIR_OVERLAY
_________________
--kirill |
|
| Back to top |
|
|
Astroman
n00b
Joined: 03 Sep 2002
Posts: 6
Location: Germany
|
| Posted: Tue Sep 03, 2002 11:51 am Post subject: |
|
|
| where is $PORTDIR_OVERLAY? it's not in the environment. |
|
| Back to top |
|
|
kirill
Apprentice
Joined: 01 Aug 2002
Posts: 183
Location: Finland
|
| Posted: Tue Sep 03, 2002 12:23 pm Post subject: |
|
|
| Astroman wrote: | | where is $PORTDIR_OVERLAY? it's not in the environment. |
put
PORTDIR_OVERLAY=/usr/local/portage
to /etc/make.conf or the environment
_________________
--kirill |
|
| Back to top |
|
|
Astroman
n00b
Joined: 03 Sep 2002
Posts: 6
Location: Germany
|
| Posted: Tue Sep 03, 2002 5:18 pm Post subject: |
|
|
alright, thx. That's good to know.
However the much more interesting thing is how to UNmask packages permanently. |
|
| Back to top |
|
|
kirill
Apprentice
Joined: 01 Aug 2002
Posts: 183
Location: Finland
|
| Posted: Tue Sep 03, 2002 5:41 pm Post subject: |
|
|
| Astroman wrote: | alright, thx. That's good to know.
However the much more interesting thing is how to UNmask packages permanently. |
Did masking work for you? Didn't work for me today 
Using Portage 2.0.34
_________________
--kirill |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Tue Sep 03, 2002 5:55 pm Post subject: |
|
|
| Astroman wrote: | | However the much more interesting thing is how to UNmask packages permanently. |
You could just copy packages.mask somewhere safe, do emerge sync, and then copy it back. It could be put in a shell script, if you like.
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
Astroman
n00b
Joined: 03 Sep 2002
Posts: 6
Location: Germany
|
| Posted: Tue Sep 03, 2002 6:25 pm Post subject: |
|
|
| rac wrote: | | Astroman wrote: | | However the much more interesting thing is how to UNmask packages permanently. |
You could just copy packages.mask somewhere safe, do emerge sync, and then copy it back. It could be put in a shell script, if you like. |
That's not nice, because that way, your packages.mask won't be up-to-date. I.e. it wouldn't contain recently unmasked packages, new masks, anything.
What should be done is something like having a personal file, holding all program-names that ought to be unmasked. The packages.mask should be updated normally and be untouched by the user. emerge now needs a little more intelligence to respect the personal unmasking likings. |
|
| Back to top |
|
|
Astroman
n00b
Joined: 03 Sep 2002
Posts: 6
Location: Germany
|
| Posted: Tue Sep 03, 2002 6:27 pm Post subject: |
|
|
| kirill wrote: | | Astroman wrote: | alright, thx. That's good to know.
However the much more interesting thing is how to UNmask packages permanently. |
Did masking work for you? Didn't work for me today
Using Portage 2.0.34 |
I haven't tried it, since I'm only interested in unmasking things at the moment. |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Tue Sep 03, 2002 6:44 pm Post subject: |
|
|
| Astroman wrote: | That's not nice, because that way, your packages.mask won't be up-to-date. I.e. it wouldn't contain recently unmasked packages, new masks, anything.
What should be done is something like having a personal file, holding all program-names that ought to be unmasked. The packages.mask should be updated normally and be untouched by the user. |
If foo 2.0 is masked, and you want it, and you unmask it, then "foo" goes in your personal "unmask" file. Then foo 2.1 comes out, and it gets masked. What to do? Believe the personal file? Believe the upstream mask?
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
Astroman
n00b
Joined: 03 Sep 2002
Posts: 6
Location: Germany
|
| Posted: Tue Sep 03, 2002 7:18 pm Post subject: |
|
|
| rac wrote: | | Astroman wrote: | That's not nice, because that way, your packages.mask won't be up-to-date. I.e. it wouldn't contain recently unmasked packages, new masks, anything.
What should be done is something like having a personal file, holding all program-names that ought to be unmasked. The packages.mask should be updated normally and be untouched by the user. |
If foo 2.0 is masked, and you want it, and you unmask it, then "foo" goes in your personal "unmask" file. Then foo 2.1 comes out, and it gets masked. What to do? Believe the personal file? Believe the upstream mask? |
I don't see the problem. At the end the status is that 'foo 2.0' is personally unmasked and 'foo 2.1' is masked by packages.mask, right?
Then I'd say, 2.0 is unmasked. 2.1 is masked. period. |
|
| Back to top |
|
|
kirill
Apprentice
Joined: 01 Aug 2002
Posts: 183
Location: Finland
|
| Posted: Tue Sep 03, 2002 7:30 pm Post subject: |
|
|
| rac wrote: | | Astroman wrote: | That's not nice, because that way, your packages.mask won't be up-to-date. I.e. it wouldn't contain recently unmasked packages, new masks, anything.
What should be done is something like having a personal file, holding all program-names that ought to be unmasked. The packages.mask should be updated normally and be untouched by the user. |
If foo 2.0 is masked, and you want it, and you unmask it, then "foo" goes in your personal "unmask" file. Then foo 2.1 comes out, and it gets masked. What to do? Believe the personal file? Believe the upstream mask? |
Why to unmask foo, you could just unmask =foo-2.0 or even >=foo-2.0. When foo-2.1 comes out and it's masked, you'll still get it if you used >=foo-2.0 in your unmask file and it will remain masked if you only unmasked =foo-2.0.
I think that this feature will (or at least should) be implemented in PORTDIR_OVERLAY -function. Then portage would still check the official packages.mask (and packages.unmask ??  ) and after that check your personal ones. Well as the latest portage ebuilds say PORTDIR_OVERLAY is beta code, so I hope it will get better by time.
_________________
--kirill |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Tue Sep 03, 2002 7:32 pm Post subject: |
|
|
| Astroman wrote: | I don't see the problem. At the end the status is that 'foo 2.0' is personally unmasked and 'foo 2.1' is masked by packages.mask, right?
Then I'd say, 2.0 is unmasked. 2.1 is masked. period. |
The syntax of packages.mask is richer than that, though, as is the universe of possible user preferences. You can mask ">= 2.0", for example. How can you tell the difference between a user that wants just one exact ebuild unmasked versus one who wants the latest and greatest? What if, for example, everything past gcc 2.95 was masked, and you wanted to install 3.1? You want updates to 3.1, like 3.1-r1, 3.1.1, but you don't want to go to 3.2?
I once proposed a profile-specific version of packages.mask, so that one could choose a "testing" profile or create a custom profile that would be appropriate for different architectures. The idea was shot down on gentoo-dev, partially in favor of the KEYWORDS feature. But another lesson I drew from Spider's message was that packages.mask is organized primarily for the convenience of developers, not for users who want to unmask things.
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Sep 09, 2002 9:30 pm Post subject: |
|
|
| rac wrote: | | packages.mask is organized primarily for the convenience of developers, not for users who want to unmask things. |
Provided changes don't interfere with the developers work, that seems like a sorry excuse.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Mon Sep 09, 2002 9:43 pm Post subject: |
|
|
| kanuslupus wrote: | | rac wrote: | | packages.mask is organized primarily for the convenience of developers, not for users who want to unmask things. |
Provided changes don't interfere with the developers work, that seems like a sorry excuse. |
As I read Spider's response to me, I imagined the scenario where (let's use glibc, as it happened recently) a new version of glibc comes out: 2.2.5-r7, which includes a fix for the sunrpc overflow and some other things. We unmask it because of the security issue. Lots of "atexit undefined" errors crop up. It is apparently broken. We need to remask -r7, and leave -r6 as the latest unmasked version.
Assume I am the glibc maintainer. I want to make one change to packages.mask, and have as many Gentoo users as possible see this change in policy the next time they sync their portage tree.
I do not want to have to describe the problem, hope that everybody affected by it sees it, all the while wading through all the duplicate bug reports that are a result of people whose package mask was overridden locally, and so they never saw that -r7 had been remasked.
As I user, sometimes I share the frustration. However, I understood (and I hope I will be corrected if I am putting words in Spider's mouth) that preserving packages.mask as a rapid one-way communication mechanism between developers and users when problems are discovered was considered a greater good than making testers' lives a bit easier. In this case, the developers are often better informed than the users, and I don't see it as an undue burden to force users to listen to what they have to say before actively choosing to ignore it.
_________________
For every higher wall, there is a taller ladder |
|
| Back to top |
|
|
taveren
Tux's lil' helper
Joined: 24 Jul 2002
Posts: 145
Location: London, Ontario
|
| Posted: Fri Sep 13, 2002 12:27 am Post subject: |
|
|
Another example of that I think this topic is referring to is, each night, I come home and run "emerge rsync" to udpate my tree. Then, I have to edit "/usr/portage/profiles/package.mask" and comment out the Mozilla entires for 1.1_beta and 1.1 since I like using the latest version and don't use Galeon, which is why 1.1 is masked in the first place. Then, I find the "gimp" entry and comment that out since the version I use is newer and I havn't had it (or its dependancies) break anything yet.
What would be nice is a file that lists the apps and versions (exactly as shown in the packages.mask file) of things that I WANT to be there. This would cause "emerge -u world" to skip over them thinking that I already have the latest version installed (which I technically do). |
|
| Back to top |
|
|
rac
Bodhisattva
Joined: 30 May 2002
Posts: 6553
Location: Japanifornia
|
| Posted: Fri Sep 13, 2002 12:53 am Post subject: |
|
|
I have read recently that drobbins is planning to implement profile-specific masking.
EDIT: went back and added link, since phong is funneling traffic to this thread.
_________________
For every higher wall, there is a taller ladder
Last edited by rac on Sun Nov 10, 2002 8:40 pm; edited 1 time in total |
|
| Back to top |
|
|
dol-sen
Retired Dev
Joined: 30 Jun 2002
Posts: 2805
Location: Richmond, BC, Canada
|
| Posted: Fri Sep 13, 2002 7:27 am Post subject: package.mask overwrites |
|
|
I started a poll and feature request related to your request as I too have found it tedious to edit or search the package.mask file to see what ebuilds are being blocked and why.
check it out here https://forums.gentoo.org/viewtopic.php?p=83765#83765 and please vote so the developers can get an idea of how many of us would like such features.
Thanks ... Brian |
|
| Back to top |
|
|
Nossie
Apprentice
Joined: 19 Apr 2002
Posts: 181
|
| Posted: Fri Sep 13, 2002 8:04 pm Post subject: Masking ebuils |
|
|
I am running a patched version of exim, so i don't want it to be automaticaly updated when I do an emerge sync followed by an update world.
There are also a couple of ebuilds that keep failing to build (docbook-sgml-utils-0.6.11-r2 that is needed by scrollkeeper-0.3.11-r1 for instance).
I wanted to mask those files, but i didn't want to edit package.mask everytime i did an emerge sync.
I made the following script that reads package names from a file (/etc/packages.mask, same format as package.mask) and updates the package.mask file after an emerge rsync.
| Code: | #!/bin/bash
emerge rsync
echo "Updating package.mask file"
for lines in `grep '' /etc/packages.mask` ; do
if [ "`grep -cx $lines /usr/portage/profiles/package.mask`" != 0 ]; then
echo "$lines already masked"
else
echo $lines >> /usr/portage/profiles/package.mask
echo "Adding $lines"
fi
done
emerge -pu world
echo "Continue with update (Yes/no) ?"
read opt;
case "$opt" in
y) emerge -u world ;exit ;;
[a-z]) exit ;;
no) exit;;
*) emerge -u world ;exit ;;
esac
|
I hope this helps someone 
Nossie |
|
| Back to top |
|
|
taveren
Tux's lil' helper
Joined: 24 Jul 2002
Posts: 145
Location: London, Ontario
|
| Posted: Tue Sep 17, 2002 5:30 pm Post subject: |
|
|
| Although this script is nice, its the wrong way around from what I want. I have to unmask packages to do the update that I want. Running your scipt as it is, and adding the exact lines that I want to /etc/packages.mask just appends the lines to the end (obviously), but the older versions are still installed. Everytime I "emerge rsync", I have comment out certain lines in package.mask. |
|
| Back to top |
|
|
taveren
Tux's lil' helper
Joined: 24 Jul 2002
Posts: 145
Location: London, Ontario
|
| Posted: Tue Sep 17, 2002 6:35 pm Post subject: |
|
|
Some quick hacking around and I came up with this. Ugly, ugly, ugly, but it works.
| Code: |
#!/bin/bash
emerge rsync
REAL_MASK="/usr/portage/profiles/package.mask"
NEW_MASK="/usr/portage/profiles/package.mask.new"
echo "Updating package.mask file"
for lines in `cat /etc/packages.mask` ; do
newline="#`echo $lines`"
cat $REAL_MASK | sed 's:'$lines':'$newline':g' > $NEW_MASK
mv $NEW_MASK $REAL_MASK
done
emerge --pretend -u world
|
The file /etc/packages.mask should look something like this:
| Code: |
=net-www/mozilla-1.1_beta
>=net-www/mozilla-1.1
>=media-gfx/gimp-1.3.5
|
Those entries will be commented out in the real package.mask file. |
|
| Back to top |
|
|
buckminst
n00b
Joined: 18 Jul 2002
Posts: 22
Location: Idaho
|
| Posted: Mon Feb 10, 2003 3:55 am Post subject: Yet another unmasking method |
|
|
Having similar desires, and being similarly shot down on adding a file that would override package.mask, I created my own bash script to handle unmasking lines in package.mask
It's not exactly elegant either, but it's been working for me =)
You can find it here.
I'd post the code here, but it's long.
Hope it's useful to other people.
_________________
Curtis Hogg [ buckminst at inconnu dot islug dot org ]
Sattinger's Law: "It works better if you plug it in!"
This post sponsored by: Frungy, the sport of kings!
Registered Linux User #202758 Sept/1997 |
|
| Back to top |
|
|
smouge
n00b
Joined: 22 Jan 2003
Posts: 66
Location: Oosterhout, the Netherlands
|
| Posted: Thu Jun 19, 2003 9:06 pm Post subject: |
|
|
I also got tired of manually updating /usr/portage/profiles/package.mask.
I'm using now the following method:
In /etc/make.conf I added the line:
PORTDIR_OVERLAY=/usr/portage.local
Example "unmasking" a package.
I use the program bacula for making back-ups. But this one has the "~x86" defined in its ebuild (unstable package).
I copied the directory
# mkdir -p /usr/portage.local/apps-admin
# cp -R /usr/portage/apps-admin/bacula /usr/portage.local/apps-admin/bacula
In the directory /usr/portage.local/apps/admin/bacula I edited the ebuild file and changed the define "~x86" into "x86". Great, now the package installs and even after an "emerge sync" it stays unmasked.
Well, this should be nothing new to you, and I'm glad this works, especially if you want to install a newer unstable version of a program and do not want to downgrade the program after each emerge sync.
I could not find a good way to mask packages and to keep them masked, even after an "emerge sync"
However I just found a way that might not be documented.
For example you want to mask the ebuild nmap-3.27-r1
Do the following:
# mkdir -p /usr/portage.local/net-analyzer
# cp -R /usr/portage/net-analyzer/nmap /usr/portage.local/net-analyzer/nmap
now edit the ebuild /usr/portage.local/net-analyzer/nmap/nmap-3.27-r1.ebuild and change the define "x86" into "~x86" or completely remove the "x86"
After having done this your nmap-3.27-r1 is masked and willot be unmasked by an "emerge sync". Unfortunately this method can only be used to mask a specified version number. Therefore if a newer version nmap-3.28 or nmap-3.27-r2 comes out, this latest version is not masked by above mentioned method. You will have to add this new version to /usr/portage.local/net-analyzer/nmap if you want this newer version to be masked as well.
I hope this can be usefull to you. |
|
| Back to top |
|
|
robmoss
Retired Dev
Joined: 27 May 2003
Posts: 2634
Location: Jesus College, Oxford
|
| Posted: Tue Sep 02, 2003 7:25 pm Post subject: |
|
|
*bump*
I know that it's easy enough now to unmask things - you just use /etc/portage/package.unmask - but have we got around to masking things on a user-level yet? For example, the situation I found myself in a while back when I wanted to mask sh-utils, fileutils and textutils in favour of coreutils? |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9527
Location: beyond the rim
|
| Posted: Tue Sep 02, 2003 7:51 pm Post subject: |
|
|
| /etc/portage/package.mask works |
|
| Back to top |
|
|
|
Portage & Programming
