Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
arch and/or packages.mask
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
ikshaar
Veteran
Veteran


Joined: 23 Jul 2002
Posts: 1339
Location: Baltimore, MD

PostPosted: Wed Nov 13, 2002 5:17 pm    Post subject: arch and/or packages.mask Reply with quote

Hi,

I didn't get the point of the new system with ~arch against the previous packages.mask.

I want to keep my system stable, so I can't use ~arch as it allows upgrade of ALL unstable packages. But on the other hand, I would like to use some not yet finished packages as grdesktop (for example) when I need them. But I cannot unmasked it, as it is not in packages.mask listing. I could do an ACCEPT_KEYWORDS="~x86" but in that case emerge will use unstable dependencies without telling me which ones are unstable and which are not.

So I don't want to sound conservative but I missed the overall usefullness of the new keyword !! and i feel stuck to use only the official released packages now.
_________________
"May God stands between you and harm in all the empty places where you must walk" - Babylon 5
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16090
Location: Colorado

PostPosted: Wed Nov 13, 2002 5:36 pm    Post subject: Reply with quote

The overall usefullness would be for those that want to bungee jump with a fraying cord.

If you pretend the ~arch options didn't exist, then you'd not have to worry about trying packages that won't unmask, since they are probably too unstable.

What you could try, is this.
Code:
# ACCEPT_KEYWORDS="~x86" emerge -p grdesktop
<you'll see a list of what it wants to install>
# ACCEPT_KEYWORDS=""
# emerge -s <list of what it wants to install>

It isn't pretty or quick, but using the emerge -s output, you'll see what versions are masked.
_________________
lolgov. 'cause where we're going, you don't have civil liberties.

In Loving Memory
1787 - 2008
Back to top
View user's profile Send private message
ikshaar
Veteran
Veteran


Joined: 23 Jul 2002
Posts: 1339
Location: Baltimore, MD

PostPosted: Wed Nov 13, 2002 6:48 pm    Post subject: Reply with quote

I tried that but ...

Code:
#root->emerge grdesktop -p

These are the packages that I would merge, in order.

Calculating dependencies ...done!
[ebuild  N   ] dev-perl/XML-DOM-1.39-r2
[ebuild  N   ] dev-perl/MIME-Base64-2.12-r2
[ebuild  N   ] dev-perl/URI-1.18-r1
[ebuild  N   ] dev-perl/Digest-MD5-2.20-r1
[ebuild  N   ] dev-perl/libnet-1.11-r1
[ebuild  N   ] dev-perl/HTML-Tagset-3.03-r2
[ebuild  N   ] dev-perl/HTML-Parser-3.26-r2
[ebuild  N   ] dev-perl/libwww-perl-5.64-r1
[ebuild  N   ] dev-perl/XML-XSLT-0.40-r1
[ebuild  N   ] app-text/docbook2X-0.6.1
[ebuild    U ] dev-libs/glib-2.0.7
[ebuild    U ] x11-libs/gtk+-2.0.8
[ebuild  N   ] net-misc/rdesktop-1.1.0.19.9.0
[ebuild  N   ] net-misc/grdesktop-0.17


That's quite a lot to test one by one with "emerge -s name". It's possible, just not very easy.

But when you said :

Quote:
If you pretend the ~arch options didn't exist, then you'd not have to worry about trying packages that won't unmask, since they are probably too unstable.


Does that mean that packages.mask is totally obsolete now ? Or will packages will go from very unstable (you have to use ~arch), to still unstable (no ~arch but still in packages.mask) to final release ?

I understand the idea to allow testing of a cutting edge system, but I was hoping to keep using portage for a not so extreme point like testing new releases without jeopardizing my all system.
_________________
"May God stands between you and harm in all the empty places where you must walk" - Babylon 5
Back to top
View user's profile Send private message
lx
Veteran
Veteran


Joined: 28 May 2002
Posts: 1012
Location: Netherlands

PostPosted: Wed Nov 13, 2002 7:18 pm    Post subject: Reply with quote

Using keywords you can do more then using the package.mask, so I think the package.mask is probably obsolete, but I've asked the same question in another post.

But the way I see it you could use "~~x86" for very unstable etc, some packages have -x86, which run fine on my system, but maybe that's the flag for very unstable or something, so why should you use a package.mask file, it's very crude and you can't differ between different architectures. In my opinion the KEYWORDS mechanism can do the same and more as the package.mask file and with time it will get obsolete.

But I might be (/probably am) overlooking something, correct me plz, ;-)

Cya lX.
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa
Back to top
View user's profile Send private message
rac
Bodhisattva
Bodhisattva


Joined: 30 May 2002
Posts: 6553
Location: Japanifornia

PostPosted: Wed Nov 13, 2002 10:19 pm    Post subject: Reply with quote

lx wrote:
Using keywords you can do more then using the package.mask, so I think the package.mask is probably obsolete, but I've asked the same question in another post.

And I think I responded there too, but I'm senile, so forgive me. I'm hoping that we will get the ability to define custom local mask files with the same syntax as packages.mask that override everything else except things on the command line (or the main packages.mask if it gets used for something like I describe below). What would be even better is if unusual one-off USE variables for particular packages could be recorded here as well. That way people could mask or unmask particular versions of packages as they wished, without worrying about what an "emerge sync" will do to their decisions.

Quote:
some packages have -x86, which run fine on my system, but maybe that's the flag for very unstable or something

Maybe. I assumed it was "definitely doesn't work".

Quote:
why should you use a package.mask file, it's very crude and you can't differ between different architectures.

I can still envision a use for packages.mask: when a security problem or some other showstopper bug is found, it can be a quick way to get the affected program off of as many Gentoo machines as quickly as possible.
_________________
For every higher wall, there is a taller ladder
Back to top
View user's profile Send private message
ikshaar
Veteran
Veteran


Joined: 23 Jul 2002
Posts: 1339
Location: Baltimore, MD

PostPosted: Thu Nov 14, 2002 3:20 pm    Post subject: Reply with quote

That would be nice to have some insights about what is this "-x86" keyword, and an overall idea of how are managed packages now (non-working, unstable,dangerously unstable,useable, stable,etc...).

packages.mask used to give me some insights (few I agree but still) about what was going on and why some packages were still masked. Don't get me wrong, I know ~arch keyword is more powerful than the mask file. I just want to understand a little bit more, the announce on the homepage of Gentoo is quite "limited" and I did not find any thread containing more infos about it.
_________________
"May God stands between you and harm in all the empty places where you must walk" - Babylon 5
Back to top
View user's profile Send private message
lx
Veteran
Veteran


Joined: 28 May 2002
Posts: 1012
Location: Netherlands

PostPosted: Thu Nov 14, 2002 9:24 pm    Post subject: Reply with quote

It would be nice to have some info where portage is heading, maybe even some discussion on it (well there's probably some development list / irc channel ps. I haven't looked for it). But the files in /var/db/pkg make it seem portage is heading already in the right direction, but just as "-x86" we can only guess, well it keeps it xciting every time you update portage, not disappointed yet, ;-)

Cya lX.
_________________
"Remember there's a big difference between kneeling down and bending over.", Frank Zappa
Back to top
View user's profile Send private message
Hypnos
Advocate
Advocate


Joined: 18 Jul 2002
Posts: 2859
Location: Omnipresent

PostPosted: Wed Mar 19, 2003 11:08 pm    Post subject: Reply with quote

Hi, I hope y'all don't mind a new addition to an old thread ....

I just want something simple, three levels of categorization for packages: stable, testing, unstable. "Stable" is what stable is now, "unstable" is for pre-release/unstable software, and "testing" is for stable (likely newly released) software but new/untested ebuilds.

For example, I want to use XFree86 4.3.0 as stable, released software, but the ebuild is still masked. I imagine something similar will occur when the GTK2 Evolution and Galeon come out -- this is an annoyance. I'd rather not use unstable software, but I don't mind trying out ebuilds for released software I'd like to use.

Thoughts?


PS: I have never used or administered Debian, so I'm not trolling! :P
Back to top
View user's profile Send private message
absinthe
Retired Dev
Retired Dev


Joined: 06 Oct 2002
Posts: 111
Location: San Francisco, CA, USA

PostPosted: Thu Mar 20, 2003 12:07 am    Post subject: Reply with quote

ikshaar wrote:
That would be nice to have some insights about what is this "-x86" keyword, and an overall idea of how are managed packages now (non-working, unstable,dangerously unstable,useable, stable,etc...).


-ARCH means "won't install" or "can't install". It's not really of any practical value except to the maintainers of secondary architectures, e.g. sparc. It tells them not to bother testing and adding keywords for architectures that are definitely unsupported.

An example where this might be used is if someone creates an ebuild which is strictly for x86 hardware. Adding -sparc -ppc -alpha (etc) would tell the people from other architectures that this ebuild is plainly not supported on anything else.
Back to top
View user's profile Send private message
adrenalin
Tux's lil' helper
Tux's lil' helper


Joined: 29 Dec 2002
Posts: 129

PostPosted: Wed Apr 23, 2003 6:06 pm    Post subject: Reply with quote

ikshaar wrote:
I tried that but ...

.
.
.



Im pretty late with this :D, though you can use another approach, when you dont want masked dependencies emerged:

Copy the masked ebuild to your portage overlay directory (PORTDIR_OVERLAY in /etc/make.conf)
Code:
# cp /usr/portage/<category>/<package>/<masked-ebuild> /usr/local/portage/<category>/<package>


Edit the KEYWORDS variable in the ebuild copy (save after editing)
Code:
replace ~<your-arch> with <your-arch> in the KEYWORDS variable


Create the digest for the package source file
Code:
# ebuild /usr/local/portage/<category>/<package>/<masked-ebuild> digest


Emerge the now 'unmasked' package

If there are any masked dependencies you probably need to repeat the procedure for these. But this procedure has 2 advantages:
'emerge -u world' wont downgrade your package
dep-clean wont refuse to work with masked packages in the world file

This works until you do an 'emerge sync' after. As for now 'emerge some-package' wants to use an unmasked version of the ebuild from /usr/portage instead of the one from PORTDIR_OVERLAY when the portage tree is synced after the 'unmask' procedure. Im not sure if this behaviour is intended. To prevent you from downgrading packages by accident (ie 'emerge -up world') you should 'touch' your customized ebuilds after each 'emerge sync':

Code:
# find /usr/local/portage -iname '*.ebuild' | xargs touch
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum