emerge -pu world - issues...

Message

X73 · Post by **X73** » Sat Dec 14, 2002 5:15 pm

Well as relatively new gentoo user, i noticed that:

on a emerge -pu world the output shows us the ebuilds avaliable , and IF you have installed something like mozilla 1.2.1

Code: Select all

[ebuild    UD] net-www/mozilla-1.0.1-r3 [1.2.1-r1]

does that mean it will install mozilla 1.0.1 even if i have 1.2.1 ?

some friends got big problems on a direct emerge -u world...

they got lot of ebuilds that where emerge'd ( -u world ) with very older versions...

couldnt it be possible to make portage *know* the more recent ebuilds we've installed ? so the emerge -pu world be really an -uPDATE ?

ps - sorry about my english

cheers

doug-x07 · Post by **doug-x07** » Sun Dec 15, 2002 11:42 am

All you need to do is pin the version of mozilla you want in /var/cache/edb/world. Put a line like this to stop mozilla being updated

Code: Select all

=net-www/mozilla-1.2.1-r1

However you may want mozilla to be updated if a newer version than 1.2.1-r1 makes into the tree or that particular version is released. To do that:

Code: Select all

>=net-www/mozilla-1.2.1-r1

Anyone know where I can pin a system package?

X73 · Post by **X73** » Sun Dec 15, 2002 2:52 pm

well thanks!

just learned something that will be very useful!

rac · Post by **rac** » Sun Dec 15, 2002 7:57 pm

doug-x07 wrote:Anyone know where I can pin a system package?

It's hard to do. The place is /etc/make.profile/packages, but unless you use a custom profile, this file gets updated by emerge sync, and your changes will be overwritten.

doug-x07 · Post by **doug-x07** » Sun Dec 15, 2002 11:38 pm

Thanks for the tip rac, works beutifully

I was going to edit in /usr/portage/package.mask. I take it from the comments that /etc/make.profile/packages has become the main place for pinning system configuration. Not sure that I quite understand how to use package.mask in that context now though.

rac wrote:unless you use a custom profile, this file gets updated by emerge sync, and your changes will be overwritten.

So if understand custom right, I could write a script that modifies the line for the version of perl in etc/make.profile/packages after a sync. That way I can keep the version of Perl I want whilst maintaining the rest of the system configuration up to date. I'm a bit wary of running and managing a custom profile that does not include other changes from syncing. Good approach?

rac · Post by **rac** » Mon Dec 16, 2002 1:45 am

doug-x07 wrote:TI take it from the comments that /etc/make.profile/packages has become the main place for pinning system configuration. Not sure that I quite understand how to use package.mask in that context now though.

The way I think of it is that /etc/make.profile/packages is positive. It tells what software must be installed by "emerge system". packages.mask is negative. It says "even though this software is available, please don't install it".

So if understand custom right,

The normal state of affairs is that /etc/make.profile is a symlink to one of the profiles in /usr/portage/profiles. What I meant by "custom" is "if you break the symlink and maintain your own profile".

I could write a script that modifies the line for the version of perl in etc/make.profile/packages after a sync.

That would certainly do it. I've also seen some comments from other posters suggesting that appending lines to these files might be sufficient. IOW, you could just tack another perl line, even if there is one in there already. The last one would win. Even if this works, I don't know that it's a good idea to rely on it, so modifying the line seems like a more reliable solution. And your concerns about losing the benefit of other changes upstream are valid.

doug-x07 · Post by **doug-x07** » Mon Dec 16, 2002 7:22 am

Thanks again for the excellent information Rac. Seeing the number of postings that have been around for the last few weeks on the subject, were you thinking of including something along these lines in the faq section? More and more people are switching to unstable for one or a few packages which means they need to know how to pin them properly without damaging everything else. If you think its an appropriate subject for faq or documentation I don't mind writing up the contents of this thread.

rac · Post by **rac** » Mon Dec 16, 2002 7:28 am

Actually, I'm waiting for carpaski to bail us all out. I'm holding out hope that relatively soon, Portage will remember the state of ACCEPT_KEYWORDS when you emerged a package, and reuse it thereafter, which will obsolete most of this. There are comments in the Portage source, notations in bug reports, and new files in /var/db/pkg lately. For example, there is now a USE file that records the state of USE flags at the time a package was emerged. I don't think it's reused yet, though.

doug-x07 · Post by **doug-x07** » Mon Dec 16, 2002 8:53 am

rac wrote:Portage will remember the state of ACCEPT_KEYWORDS when you emerged a package, and reuse it thereafter, which will obsolete most of this.

Probably a very good idea, I think playing around with the masks is inherently dangerous, especially for system packages, unless you are fully aware of the dangers. It makes it just to easy to come up with your own incoherent system and goes against the grain of the original use of masks as a safeguard against such things. Convenient work around in the mean time though !!