* Daniel da Veiga [EMAIL PROTECTED] wrote:
snip
Also, the world file is a simple way to keep a package version (by
removing it from world), for instance, I don't wanna upgrade mysql
with my nightly emerge -uDN world, so, its not in my world file.
Isn't there any way for nailing it down to
Good afternoon,
I would like to ask what advantages does one gain from (not) putting
packages in the world file?
I know the use of emerge --oneshot some-packages emerges packages
without recording them in the world set. I also know that all the
packages installed as dependencies don't get
On Wed, 05 Jul 2006 12:48:31 +0300, Daniel wrote:
I know the use of emerge --oneshot some-packages emerges packages
without recording them in the world set. I also know that all the
packages installed as dependencies don't get recorded in the world set
either.
I see only one advantage in
Daniel wrote:
BUT...What happens if there are critical updates for packages not
listed in the world?
They won't get installed. That's why I always do emerge --deep --update
(or rather: emerge -Duvat), as then packages which are installed to
meet dependencies, will also get updated.
But you'll
Neil Bothwick wrote:
The only time I use --oneshot for new installs is when trying a package
to see if I want it. If I do, I add it to world with --noreplace. If I
don't find it useful, my next emerge --depclean reminds me to remove it.
I use --oneshot, when the compilation of a package
On Wed, 05 Jul 2006 12:18:20 +0200, Alexander Skwar wrote:
But you'll still miss some packages this way - packages which aren't
in the world file and which are also no dependency of *CURRENTLY*
installed packages. Those are normally packages, which aren't used
anymore and could be removed. I
Neil Bothwick wrote:
On Wed, 05 Jul 2006 12:18:20 +0200, Alexander Skwar wrote:
But you'll still miss some packages this way - packages which aren't
in the world file and which are also no dependency of *CURRENTLY*
installed packages. Those are normally packages, which aren't used
anymore
Daniel wrote:
Neil Bothwick wrote:
On Wed, 05 Jul 2006 12:18:20 +0200, Alexander Skwar wrote:
But you'll still miss some packages this way - packages which aren't
in the world file and which are also no dependency of *CURRENTLY*
installed packages. Those are normally packages, which
Neil Bothwick wrote:
Now portage has no idea of which packages
are there because you want them, which are there because they are
dependencies of something you want and which are redundant cruft installed
as a dependency of a package you no longer have installed.
On your system, your
Daniel Iliev wrote:
I have no problem with the redundant cruft - when I want just to try
some package I do emerge --pretend and record the list of dependencies
it wants to pull-in. If I decide the package is not useful to me, I
un-emerge not only the package, but also the dependencies it had
On Wed, 05 Jul 2006 15:43:53 +0300, Daniel Iliev wrote:
That is correct. What are the disadvantages besides the longer seeks for
updates?
What longer seeks? --update only check one level of dependencies for
updates, a few seconds at most. That's nothing compared with the time you
could spend
Alexander, Neil thank you for pointing me out this problem.
I think both of you refer to the same scenario and Alexander illustrated
it with an example. For clarity I'll use the same letters to substitute
package names in my next question.
1) I install a which pulls-in c
2) I *manually* install
On Wed, 2006-07-05 at 15:16 +0200, Alexander Skwar wrote:
The basic problem here is, that there's no way to see, which packages
depend on a given package - at least I don't know how to find that
out.
equery depends given package name
Not always 100% accurate though, as someone politely
On Wed, 05 Jul 2006 17:29:16 +0300, Daniel Iliev wrote:
1) I install a which pulls-in c
2) I *manually* install c. I install a
3) I Install b. b depends on c. b doesn't pull-in c because
c is already *manually* installed along with a
4) I uninstall a
5) I *manually* uninstall c
6) b
On 7/5/06, Daniel Iliev [EMAIL PROTECTED] wrote:
That is correct. What are the disadvantages besides the longer seeks for
updates?
Another disadvantage is that you defeat a big reason for having USE
flags. For example, if you merge pkg A that USEs X to depend on pkg
B, and you have X in your
Neil Bothwick wrote:
so you go to a lot of trouble to circumvent portage's dependency
handling, then you rely on portage to fix things up after your break
them. You need to keep lists of what you have merged and unmerged simply
to compensate for having broken portage's own list for no good
Richard Fish wrote:
If you later take X out of your use flags, and do an emerge -DNuv
world, the A no longer depends on B. But since it is still in your
world file, portage will assume you want this package, and continue to
compile updates for it with each new version. That can be a pretty
On 7/5/06, Daniel Iliev [EMAIL PROTECTED] wrote:
Neil Bothwick wrote:
Now portage has no idea of which packages
are there because you want them, which are there because they are
dependencies of something you want and which are redundant cruft installed
as a dependency of a package you no
On 7/5/06, Daniel Iliev [EMAIL PROTECTED] wrote:
Why not just merge the
top-level package, and if you don't like it, unmerge and use
--depclean --pretend to figure out what can safely be removed?
Because if I decide to keep it, all dependencies it pulls-in don't get
updated until the
Daniel da Veiga wrote:
You're manually doying stuff that portage should do. This breaks
portage system, gives you more trouble (because you have to manually
undo stuff in order to not break your dependency list) and have
turned the whole dependency check lists and ebuils dependency check
Richard Fish wrote:
Not if you use --deep on your updates. Then dependancies are also
considered for updates. Some people here will tell you that --deep is
troublesome, but I am not one of them, and it seems like what you want
to do.
Then what is the purpose of:
emerge --update world w/o
On 7/5/06, Daniel Iliev [EMAIL PROTECTED] wrote:
Daniel da Veiga wrote:
You're manually doying stuff that portage should do. This breaks
portage system, gives you more trouble (because you have to manually
undo stuff in order to not break your dependency list) and have
turned the whole
On 7/5/06, Daniel Iliev [EMAIL PROTECTED] wrote:
Then what is the purpose of:
emerge --update world w/o --deep?
To update only the packages in world, without updating dependancies.
As I think I mentioned, some people do not like using --deep, because
they don't necessarily want to update all
Daniel da Veiga wrote:
I'll just quote the emerge man page, that is pretty clear there:
--snip
Note the words DIRECT dependencies. So, your command emerge
--update --deep world is in fact just emerge world, because every
direct/indirect dependency is part of your world file. Your way
On Wed, 05 Jul 2006 19:53:42 +0300, Daniel Iliev wrote:
Neil Bothwick wrote:
What happens if you reboot after unmerging c, and its absence causes
the system to fail to boot? What if you remove something that stops
emerge working?
Highly unlikely. For two reasons:
1) How come that
Daniel wrote:
Good afternoon,
I would like to ask what advantages does one gain from (not) putting
packages in the world file?
I know the use of emerge --oneshot some-packages emerges packages
without recording them in the world set. I also know that all the
packages installed as
Daniel Iliev wrote:
5) The best reason for manual removing individual packages from the
world set is to prevent them from upgrading.
I wouldn't call that a good reason. /etc/portage is there for that kind
of thing. If you remove a package from world, and nothing depends on
it, then it'll
27 matches
Mail list logo
