Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 14741 - Wishlist: emerge unmask <name> and more!
Summary: Wishlist: emerge unmask <name> and more!
Status: RESOLVED DUPLICATE of bug 13616
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 14865 16026 23861 (view as bug list)
Depends on: 13616
Blocks:
  Show dependency tree
 
Reported: 2003-01-29 13:00 UTC by Edulix
Modified: 2011-10-30 22:37 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edulix 2003-01-29 13:00:51 UTC
It's simple and it will help a lot.

For example I could do:

"emerge unmask gaim-cvs". And it could be unmasked!. Then I could do "emerge
gaim-cvs". Don't know if it's a good idea to unmask all the dependcies, why not
with another feature "emerge unmask-dependencies gaim-cvs". And then, it will be
awesome to could do "emerge re-mask-dependencies gaim-cvs" and to mask the
dependences I masked before :P.

And, for directly not have to unmask it, only emerge masked gaim-cvs (emerge -m
gaim-cvs?), with all the masked dependencies.

I've got another suggestion: What about a log for the dependencies that every
installation of a packet, and then to could uninstall the packet and all the
dependencies I installed ? "emerge unmerge-with-installed-dependencies
gaim-cvs" (a bit long, I'm not a english men, I think you know how to call it
smaller ;-) ).

Isn't it a good a idea ? I think that all of this isn't so difficult to do, but
you are the programmers there. You've go the last word!

See you again,
                Edulix.
Comment 1 SpanKY gentoo-dev 2003-02-19 15:51:01 UTC
*** Bug 16026 has been marked as a duplicate of this bug. ***
Comment 2 Francisco León 2003-02-19 16:04:37 UTC
Not exactly the way my duped bug wants to handle this, so i paste my bug here:

emerge -up world could have a flag called --unstable that it would 
automatically enable ~x86 or your arch so it would show the latest versions of 
portage.

Also, emerge package --unstable could install the latest package in the portage 
tree. That way we wouldn't have to edit make.conf every time...

Emerge -s package --unstable would show the latest unstable build on portage 
too... You get the idea
Comment 3 SpanKY gentoo-dev 2003-02-25 15:23:18 UTC
*** Bug 14865 has been marked as a duplicate of this bug. ***
Comment 4 Per Cederberg 2003-02-27 16:55:23 UTC
Another variation (with a more classic flag name) could be:

emerge --force <ebuild>
Comment 5 Axxackall 2003-03-04 22:27:37 UTC
Forcing the big chain of updates to accept the unstable flag will give you a bunch of unstable packages. 

For example if I upgrade to xfree-4.3 with ACCEPT_KEYWORD="~x86" at the result it will be more of unstable packages than if I manually go through the chain (each time calling "emerge -p xfree") to find out and unmask only required packages.

But here my problem is not finished. What will happen with "emerge -u world" after next "emerge rsync"? The answer is: I have to unmask thos packages again, otherwise they will be downgraded.

I predict the advise: inject your unmasked ones to the world file. Another problem: the world file syntx doesn't accept ">=x11-base/xfree-4.3.0", so at the day xfree-4.3.1 STABLE will come I'll have to wake up and "uninject" xfree, or I'll stick to the obsolete version of it.

My two cents:

(A) improve the world-file syntax by ">=" operator;

(B) import (inherit) IMPLICITLY files with user-defined variables (USE, CFLAGS) from /usr/local/portage or /etc/use.d or other place.

Basically - give users more control (when they want it).
Comment 6 Per Cederberg 2003-03-05 06:12:52 UTC
I think there are a number of issues at hand here:

1. A simpler way to unmask ebuilds on the command-line. 
   ACCEPT_KEYWORDS="~x86" just seems too cryptical and 
   ad hoc to many users.

2. A finer granularity unmasking, allowing you to unmask
   only the package itself, not its dependencies (if not
   required of course). Optionally you could do both (as 
   today), but that seems like the less frequent case.

3. Avoiding downgrades to unmasked packages. Some easy
   mechanism to keep the unstable packages on the system.
   (Doesn't -U already do this?)

4. Package-specific USE and CFLAGS. This is related to 
   #6677 and #13616, although not completely the same.

And to complicate things, it has also been suggested to 
split the "stable" and "masked" categories into something
a bit more granular -- stable, unstable, security, bugfix...
This would make some of the issues here obsolete. 

It has been mentioned in #5835 and here:
http://forums.gentoo.org/viewtopic.php?t=39169
Comment 7 Paul Kronenwetter 2003-06-24 19:43:16 UTC
I have a suggestion for, or addition to, this comment: Some easy mechanism to keep the unstable packages on the system.

1) Have portage register a preference that the unstable version of a particular package be recorded in the portage tree.  Then when that package is updated again, the (new) unstable version is used, instead of the next (possibly lower) stable version.   Essentially remember that I like to use ~x86 of cdrecord instead of the stable version.

2) Have two additional environment variables for /etc/make.conf:
USE_UNSTABLE="cdrecord xfree86 gabber"
USE_STABLE="alsa-driver gentoo-sources gaim"

USE_UNSTABLE would be referenced when ACCEPT_KEYWORDS references the stable architecture.  USE_STABLE would be referenced when ACCEPT_KEYWORDS references the unstable arch.  I'm not sure how good or useful USE_STABLE would be.

Both of these would allow very selective identification of the unstable packages  a user wants even through dependencies.  Ie. if I wanted unstable gaim but stable gtkspell it could be easily handled.  Rather than now merging gtkspell manually, then installing ~x86 gaim.

I don't know if there's room in the database that portage keeps for an "I like the ~ version of this package."  I have a feeling that'll take more work.  It's a less obvious solution for someone who forgets setting the preference then wonders why they keep getting unstable kernels etc...

Yes, I know. It'll get done when code is produced.  I'll look into hacking together the USE_UNSTABLE and put a patch here for review.  I have an interest in that one.  
Comment 8 Per Cederberg 2003-06-25 00:54:13 UTC
Paul,

Before you start off implementing your idea, please have a second
read of Axxackall's comment above. I think his solutions adresses
what we *really* want in a very tidy and minimalistic way. It would
also solve a bunch of other issues if things worked that way:

1. Improved world file syntax (solves the issue with downgrading).

2. Per package USE, CFLAGS, ACCEPT_KEYWORDS (solves the issues 
   with conflicting USE flags, and keeping up to date with 
   specific unstable packages). Having a make.local in PORTAGE_OVERLAY
   for each package would allow you to specify ACCEPT_KEYWORDS="~x86"
   for all the packages you want unstable.

The best part with these two suggestions is that they don't intrude
very much in the current state of affairs. I.e. patches with these
resolutions would stand a better chance to get accepted (me thinks).

Anyway, just my thoughts.
Comment 9 Paul Kronenwetter 2003-06-25 15:54:24 UTC
Per - I like both of those suggestions.  

The world file modification would allow you to use something that works.  At the same time you'll be back on the stable branch when that version, or a later one, is marked stable.

The second allows for the pension to stay at the bleeding edge forever on a package.

Does this path sound good to everyone/anyone else?  Does it address the problem described and/or augmented here?
Comment 10 SpanKY gentoo-dev 2003-07-02 09:51:44 UTC
*** Bug 23861 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Willmann 2003-07-03 09:44:10 UTC
Hi!
I created a patch for emerge, it's in Bug# 23861, the comment above.

It adds --masked or -m to the list of options which basically does nothing else than an "ACCEPT_KEYWORDS="~arch" emerge" would do. But I totally agree, that a per package ACCEPT_KEYWORDS would be a very pleasant feature to have. But I guess I don't know python good enough for theese changes...
Comment 12 Marius Mauch (RETIRED) gentoo-dev 2003-11-15 19:32:28 UTC
That's what package.keywords is for

*** This bug has been marked as a duplicate of 13616 ***