[gentoo-user] package conflict on update

[gentoo-user] package conflict on update

[Trenton Adams]

Ok, so I get the output below when trying to merge after a sync today.
 My guess is that the openmotif package was made into two separate
packages, correct?

To the portage developers, how could this be handled?  Perhaps emerge
could somehow figure out the reason for such a conflict, and then
automatically unmerge the original package?

The fix for this was to "emerge --unmerge openmotif", and then
re-emerge it.  Then I was finally able to do a system update.  Do you
want this reported as a bug, or is it already?


[00:16 root@joseph data] # emerge --ask --update --deep --newuse
--buildpkg world

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

Calculating world dependencies ...done!
[blocks B     ] =x11-libs/openmotif-2.2.3-r3 (is blocking
x11-libs/motif-config-0.9)
[ebuild     U ] sys-devel/gcc-config-1.3.12-r5 [1.3.12-r4]
[ebuild     U ] sys-apps/man-pages-2.18 [2.16]
[ebuild  N    ] x11-libs/cairo-1.0.2
[ebuild     U ] dev-libs/glib-2.8.4 [2.6.5]
[ebuild     U ] dev-libs/atk-1.10.3 [1.10.1]
[ebuild     U ] x11-libs/pango-1.10.2 [1.8.1-r1]
[ebuild     U ] x11-libs/gtk+-2.8.8 [2.6.10-r1]
[ebuild     U ] dev-libs/libgcrypt-1.2.2-r1 [1.2.1]
[ebuild     U ] sys-apps/module-init-tools-3.2.1 [3.0-r2]
[ebuild     U ] net-analyzer/ethereal-0.10.14 [0.10.13-r2]
[ebuild  N    ] x11-libs/motif-config-0.9
[ebuild     U ] x11-libs/openmotif-2.2.3-r8 [2.2.3-r3]
[ebuild     U ] media-sound/alsa-headers-1.0.10 [1.0.10_rc3]
[ebuild     U ] media-libs/alsa-lib-1.0.10 [1.0.10_rc3]
[ebuild     U ] kde-base/kpdf-3.4.3-r3 [3.4.3-r2]
[ebuild     U ] sys-apps/findutils-4.1.20-r2 [4.1.20-r1]
[ebuild  N    ] virtual/libstdc++-3.3
[ebuild     U ] app-portage/gentoolkit-0.2.2_pre1 [0.2.1_rc3]

!!! Error: The above package list contains packages which cannot be installed
!!!        on the same system.

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: package conflict on update

[Trenton Adams]

Oh, if someone does make emerge detect how to resolve the conflict,
perhaps it should ask the user if they would like to continue with the
unmerge/re-emerge.  After all, it could be a critical system utility
that is running.

On 1/5/06, Trenton Adams <trenton.d.adams@gmail.com> wrote:
> Ok, so I get the output below when trying to merge after a sync today.
>  My guess is that the openmotif package was made into two separate
> packages, correct?
>
> To the portage developers, how could this be handled?  Perhaps emerge
> could somehow figure out the reason for such a conflict, and then
> automatically unmerge the original package?
>
> The fix for this was to "emerge --unmerge openmotif", and then
> re-emerge it.  Then I was finally able to do a system update.  Do you
> want this reported as a bug, or is it already?
>
>
> [00:16 root@joseph data] # emerge --ask --update --deep --newuse
> --buildpkg world
>
> These are the packages that I would merge, in order:
>
> Calculating world dependencies ...done!
> [blocks B     ] =x11-libs/openmotif-2.2.3-r3 (is blocking
> x11-libs/motif-config-0.9)
> [ebuild     U ] sys-devel/gcc-config-1.3.12-r5 [1.3.12-r4]
> [ebuild     U ] sys-apps/man-pages-2.18 [2.16]
> [ebuild  N    ] x11-libs/cairo-1.0.2
> [ebuild     U ] dev-libs/glib-2.8.4 [2.6.5]
> [ebuild     U ] dev-libs/atk-1.10.3 [1.10.1]
> [ebuild     U ] x11-libs/pango-1.10.2 [1.8.1-r1]
> [ebuild     U ] x11-libs/gtk+-2.8.8 [2.6.10-r1]
> [ebuild     U ] dev-libs/libgcrypt-1.2.2-r1 [1.2.1]
> [ebuild     U ] sys-apps/module-init-tools-3.2.1 [3.0-r2]
> [ebuild     U ] net-analyzer/ethereal-0.10.14 [0.10.13-r2]
> [ebuild  N    ] x11-libs/motif-config-0.9
> [ebuild     U ] x11-libs/openmotif-2.2.3-r8 [2.2.3-r3]
> [ebuild     U ] media-sound/alsa-headers-1.0.10 [1.0.10_rc3]
> [ebuild     U ] media-libs/alsa-lib-1.0.10 [1.0.10_rc3]
> [ebuild     U ] kde-base/kpdf-3.4.3-r3 [3.4.3-r2]
> [ebuild     U ] sys-apps/findutils-4.1.20-r2 [4.1.20-r1]
> [ebuild  N    ] virtual/libstdc++-3.3
> [ebuild     U ] app-portage/gentoolkit-0.2.2_pre1 [0.2.1_rc3]
>
> !!! Error: The above package list contains packages which cannot be installed
> !!!        on the same system.
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Tom Martin]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Thu, 5 Jan 2006 00:29:57 -0700
Trenton Adams <trenton.d.adams@gmail.com> wrote:

> Ok, so I get the output below when trying to merge after a sync today.
>  My guess is that the openmotif package was made into two separate
> packages, correct?
> 
> To the portage developers, how could this be handled?  Perhaps emerge
> could somehow figure out the reason for such a conflict, and then
> automatically unmerge the original package?

Not really a question to the portage developers -- just unmerge
openmotif (the blocker) and continue as normal.

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/5/06, Tom Martin <slarti@gentoo.org> wrote:
> On Thu, 5 Jan 2006 00:29:57 -0700
> Trenton Adams <trenton.d.adams@gmail.com> wrote:
>
> > Ok, so I get the output below when trying to merge after a sync today.
> >  My guess is that the openmotif package was made into two separate
> > packages, correct?
> >
> > To the portage developers, how could this be handled?  Perhaps emerge
> > could somehow figure out the reason for such a conflict, and then
> > automatically unmerge the original package?
>
> Not really a question to the portage developers -- just unmerge
> openmotif (the blocker) and continue as normal.

So what happens to the unknowing user that doesn't figure out that the
package was split into multiple packages?  Especially if it's a
critical system package.  They may not like the idea of unmerging the
package, and re-merging.

>
> --
> Tom Martin, http://dev.gentoo.org/~slarti
> AMD64, net-mail, shell-tools, vim, recruiters
> Gentoo Linux
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Holly Bostick]

Trenton Adams schreef:
> On 1/5/06, Tom Martin <slarti@gentoo.org> wrote:
> 
>> On Thu, 5 Jan 2006 00:29:57 -0700 Trenton Adams
>> <trenton.d.adams@gmail.com> wrote:
>> 
>> 
>>> Ok, so I get the output below when trying to merge after a sync
>>> today. My guess is that the openmotif package was made into two
>>> separate packages, correct?
>>> 
>>> To the portage developers, how could this be handled?  Perhaps
>>> emerge could somehow figure out the reason for such a conflict,
>>> and then automatically unmerge the original package?
>> 
>> Not really a question to the portage developers -- just unmerge 
>> openmotif (the blocker) and continue as normal.
> 
> 
> So what happens to the unknowing user that doesn't figure out that
> the package was split into multiple packages?  Especially if it's a 
> critical system package.  They may not like the idea of unmerging the
>  package, and re-merging.
> 
> 

You actually don't have to 're-merge'; the openmotif upgrade will be
installed by motif-config.

This is actually standard operating procedure; the normal way to resolve
the vast majority of blocks is to unmerge the package that is blocking
something.

The fact that one (installed) package blocks another (to-be-installed)
package is almost always because the to-be-installed package replicates
the functionality of the currently-installed package, contains it, or
the currently-installed package must be specifically installed as a
dependency of the to-be-installed package. Sometimes the issue is that
the to-be-installed package breaks with the currently-installed package
remaining installed.

But in all of these cases, the solution is to unmerge the blocking
package, and then trust Portage (and the devs) to sort everything out so
that you don't lose any functionality. This trust is 98% of the time
well-placed.

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Thu, 5 Jan 2006 11:10:38 +0000, Tom Martin wrote:

> > To the portage developers, how could this be handled?  Perhaps emerge
> > could somehow figure out the reason for such a conflict, and then
> > automatically unmerge the original package?

> Not really a question to the portage developers -- just unmerge
> openmotif (the blocker) and continue as normal.

If would be nice is portage had a means for developers to handle these
types of conflicts in the ebuild. A similar thing happened recently with
xpdf/poppler, it happened with some FTP servers and the ftp-base package
not long ago. I realise it is not possible to handle all conflicts, but
with some instances, like this one, the conflict is expected. even if
there were just a means to print a message if a package hits a block,
something like

if_blocked_by('openmotif')
	ewarn "You must unmerge openmotif before proceeding"


-- 
Neil Bothwick

I am Tagline of Borg. Prepare to assimilate me.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Devon Miller]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

I ran into this a few days ago. Ah ha, I thought, I just need to update
openmotif.

Nope, openmotif depended on openmotif-config which was blocked by openmotif.
I tried unmasking one, the other, then both all to noavail.
Finally, in frustation I did emerge unmerge openmotif, emerge openmotif
and it just worked (pulling in openmotif-config in the process)

I for one would like to see portage be a bit smarter about this. It already
calculates a dependancy list.

Would it be possible to detect the case where the blocker is part of the
dependancy list (ie, will be installed anyway) and automatically offer to
unmerge the conflicting package?

Or, is this a situation that should be handled with slots?  Eg, slot 1 hols
openmotif, slot 2 holds openmotif-config & newer openmotif.

I can't wait to see the hoop jumping xorg-x11-7.0 will require.

-dcm-


On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> On Thu, 5 Jan 2006 11:10:38 +0000, Tom Martin wrote:
>
> > > To the portage developers, how could this be handled?  Perhaps emerge
> > > could somehow figure out the reason for such a conflict, and then
> > > automatically unmerge the original package?
>
> > Not really a question to the portage developers -- just unmerge
> > openmotif (the blocker) and continue as normal.
>
> I realise it is not possible to handle all conflicts, but
> with some instances, like this one, the conflict is expected. even if
> there were just a means to print a message if a package hits a block,
> something like
>
> if_blocked_by('openmotif')
>         ewarn "You must unmerge openmotif before proceeding"
>
>
> --
> Neil Bothwick
>
> I am Tagline of Borg. Prepare to assimilate me.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2149 bytes --]

Re: [gentoo-user] package conflict on update

[Tom Martin]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

On Thu, 5 Jan 2006 11:41:22 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> If would be nice is portage had a means for developers to handle these
> types of conflicts in the ebuild. A similar thing happened recently
> with xpdf/poppler, it happened with some FTP servers and the ftp-base
> package not long ago. I realise it is not possible to handle all
> conflicts, but with some instances, like this one, the conflict is
> expected. even if there were just a means to print a message if a
> package hits a block, something like
> 
> if_blocked_by('openmotif')
> 	ewarn "You must unmerge openmotif before proceeding"

An error message like that doesn't really tell the user anything that he
doesn't already know.

It would be more useful if some information was provided:

if blocked_by >=x11-libs/openmotif-1.2.3 ; then
	eblockinfo "Due to changes with blah, it is recommended that"
	eblockinfo "you foobar. See http://bugs.gentoo.org/123456."
fi

But then, at what point would this information be echoed to the user?
It would have to be during the same pre-merge phase that the blocking
errors appear. Then again, I don't really see any gaping problems with
the current system; once someone has encountered their first pair of
blocking packages, they then understand how to fix blockers in future.
I doubt it's worth the effort.

/shrug
-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Richard Fish]

On 1/5/06, Tom Martin <slarti@gentoo.org> wrote:
> It would be more useful if some information was provided:
>
> if blocked_by >=x11-libs/openmotif-1.2.3 ; then
>         eblockinfo "Due to changes with blah, it is recommended that"
>         eblockinfo "you foobar. See http://bugs.gentoo.org/123456."
> fi

Sounds more like information that should be available in the coming
emerge --news system.

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Thu, 5 Jan 2006 16:08:04 +0000, Tom Martin wrote:

> > if_blocked_by('openmotif')
> > 	ewarn "You must unmerge openmotif before proceeding"
> 
> An error message like that doesn't really tell the user anything that he
> doesn't already know.

It may not say anything you or I don't know, but from the number of posts
to this list about blockers, it would clearly help some people.

> It would be more useful if some information was provided:
> 
> if blocked_by >=x11-libs/openmotif-1.2.3 ; then
> 	eblockinfo "Due to changes with blah, it is recommended that"
> 	eblockinfo "you foobar. See http://bugs.gentoo.org/123456."
> fi
> 
> But then, at what point would this information be echoed to the user?
> It would have to be during the same pre-merge phase that the blocking
> errors appear.

Yes, so instead of rushing to this list or the forums, they can do what
the message tells them and be on their way. The current messages are only
useful if you already understand how and why blocks happen, and how to
deal with them.


-- 
Neil Bothwick

If you got the words it does not mean you got the knowledge.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 5 Jan 2006 11:10:38 +0000, Tom Martin wrote:
>
> > > To the portage developers, how could this be handled?  Perhaps emerge
> > > could somehow figure out the reason for such a conflict, and then
> > > automatically unmerge the original package?
>
> > Not really a question to the portage developers -- just unmerge
> > openmotif (the blocker) and continue as normal.
>
> If would be nice is portage had a means for developers to handle these
> types of conflicts in the ebuild. A similar thing happened recently with
> xpdf/poppler, it happened with some FTP servers and the ftp-base package
> not long ago. I realise it is not possible to handle all conflicts, but
> with some instances, like this one, the conflict is expected. even if
> there were just a means to print a message if a package hits a block,
> something like
>
> if_blocked_by('openmotif')
>         ewarn "You must unmerge openmotif before proceeding"

Yes, or as follows...

if_blocked_by('openmotif')
  auto_unmerge('openmotif')
  # continue with merge which should automatically be merging openmotif anyhow.

>
>
> --
> Neil Bothwick
>
> I am Tagline of Borg. Prepare to assimilate me.
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 5 Jan 2006 16:08:04 +0000, Tom Martin wrote:
>
> > > if_blocked_by('openmotif')
> > >     ewarn "You must unmerge openmotif before proceeding"
> >
> > An error message like that doesn't really tell the user anything that he
> > doesn't already know.
>
> It may not say anything you or I don't know, but from the number of posts
> to this list about blockers, it would clearly help some people.

Yes, and I've noticed there's a big problem with the linux community
at large.  People that know and understand linux have a lot of the
times not helped the "open source" intiative, in that they like things
to be difficult, because it makes them somehow seem smarter.  In all
reality, it doesn't take a genius to use linux, just someone who likes
to read a whole lot.

Now i'm not saying this is a problem with the people working on
gentoo, so please don't think that I am.  But, if you do feel that
way, perhaps you should think twice, and actually support users.  I've
always felt that Linux in general could easily surpass windows in
usage, *IF* the linux community would make things more user friendly. 
For example, if I didn't have to read the documentation to get
something basic to work, then it's user friendly.  That doesn't mean
you have to remove flexibility either.  I've seen gui utilities in
windows that had full command line support.  If you provide command
line options, the GUI doesn't start.  So, one can have user friendly
applications without sacrificing flexibility.

When I first started with gentoo, I was ready to give up.  Not because
I didn't know what I was doing with linux, but because I don't really
have the time to read a whole whack of documentation, and the
documntation is not in a nice point form format for those that do know
what they are doing anyhow.  Take the gentoo quick install version of
the gentoo hand book.  It no longer tells you what commands to
actually run.  It just describes what to do, which is of VERY little
value.  Luckily I kept a printed copy of the old quick install around,
becuse I have no use for the new version.  Why someone would remove
all that useful information from a quick install guide, only to make a
lot less useful, I don't know.

>
> > It would be more useful if some information was provided:
> >
> > if blocked_by >=x11-libs/openmotif-1.2.3 ; then
> >       eblockinfo "Due to changes with blah, it is recommended that"
> >       eblockinfo "you foobar. See http://bugs.gentoo.org/123456."
> > fi
> >
> > But then, at what point would this information be echoed to the user?
> > It would have to be during the same pre-merge phase that the blocking
> > errors appear.
>
> Yes, so instead of rushing to this list or the forums, they can do what
> the message tells them and be on their way. The current messages are only
> useful if you already understand how and why blocks happen, and how to
> deal with them.

EXACTLY.

>
>
> --
> Neil Bothwick
>
> If you got the words it does not mean you got the knowledge.
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

Oh, and one other thing.  This should also be done for packages that
get moved to different categories, because I've been getting errors
like the following lately...

Calculating world dependencies |
emerge: there are no ebuilds to satisfy ">=dev-perl/PodParser-1.22".
(dependency required by "mail-filter/spamassassin-3.1.0" [binary])

In this case, this simply means that dev-perl/PodParser has moved to a
different category, and the old spamassassin binary package couldn't
find it anymore, because it only knows about the PodParser in the old
category, not the new category.  I checked the xorg-x11 ebuild, and it
was fine.  It was the binary that still had problems, so I had to
re-merge it without --usepkg.  If I recall correctly, I also would
have had to remove the file "/var/cache/edb/remote_metadata.pickle",
but I started using NFS for my portage instead.  That file has
information about packages, and their dependencies, so I looked in it,
and it had the wrong information.  It had the "dev-perl/PodParser"
info, instead of the "perl-core/PodParser" info.

On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 5 Jan 2006 16:08:04 +0000, Tom Martin wrote:
>
> > > if_blocked_by('openmotif')
> > >     ewarn "You must unmerge openmotif before proceeding"
> >
> > An error message like that doesn't really tell the user anything that he
> > doesn't already know.
>
> It may not say anything you or I don't know, but from the number of posts
> to this list about blockers, it would clearly help some people.
>
> > It would be more useful if some information was provided:
> >
> > if blocked_by >=x11-libs/openmotif-1.2.3 ; then
> >       eblockinfo "Due to changes with blah, it is recommended that"
> >       eblockinfo "you foobar. See http://bugs.gentoo.org/123456."
> > fi
> >
> > But then, at what point would this information be echoed to the user?
> > It would have to be during the same pre-merge phase that the blocking
> > errors appear.
>
> Yes, so instead of rushing to this list or the forums, they can do what
> the message tells them and be on their way. The current messages are only
> useful if you already understand how and why blocks happen, and how to
> deal with them.
>
>
> --
> Neil Bothwick
>
> If you got the words it does not mean you got the knowledge.
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:

> > something like
> >
> > if_blocked_by('openmotif')
> >         ewarn "You must unmerge openmotif before proceeding"
> 
> Yes, or as follows...
> 
> if_blocked_by('openmotif')
>   auto_unmerge('openmotif')
>   # continue with merge which should automatically be merging openmotif
> anyhow.

Absolutely not! I don't want portage removing something I may be using at
the time without my saying so.


-- 
Neil Bothwick

I am in total control, but don't tell my wife.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Richard Fish]

On 1/5/06, Trenton Adams <trenton.d.adams@gmail.com> wrote:
> Calculating world dependencies |
> emerge: there are no ebuilds to satisfy ">=dev-perl/PodParser-1.22".
> (dependency required by "mail-filter/spamassassin-3.1.0" [binary])

This is something that sometimes occurs when you get an out-of-sync
portage tree (you are syncing at the same time as the mirror is
updating).

The fix is to just emerge --sync again.

It can also happen if you use NFS for portage but do not keep the
cache up-to-date.

> re-merge it without --usepkg.  If I recall correctly, I also would
> have had to remove the file "/var/cache/edb/remote_metadata.pickle",

The portage cache should be updated automatically at the end of every
sync.  So no, removing this file would not be necessary.

> but I started using NFS for my portage instead.  That file has
> information about packages, and their dependencies, so I looked in it,
> and it had the wrong information.

Are you also using NFS for /var/cache/edb?  If not, then you need to
run emerge --metadata.

-Richard

PS: Please avoid top-posting here.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Bothwick wrote:
| On Thu, 5 Jan 2006 11:10:38 +0000, Tom Martin wrote:
| 
|>> To the portage developers, how could this be handled?  Perhaps emerge
|>> could somehow figure out the reason for such a conflict, and then
|>> automatically unmerge the original package?
| 
|> Not really a question to the portage developers -- just unmerge
|> openmotif (the blocker) and continue as normal.
| 
| If would be nice is portage had a means for developers to handle these
| types of conflicts in the ebuild. A similar thing happened recently with
| xpdf/poppler, it happened with some FTP servers and the ftp-base package
| not long ago. I realise it is not possible to handle all conflicts, but
| with some instances, like this one, the conflict is expected. even if
| there were just a means to print a message if a package hits a block,
| something like
| 
| if_blocked_by('openmotif')
| 	ewarn "You must unmerge openmotif before proceeding"
| 

It would be icky to have to specify blocker logic/messages like that.  There's actually an open bug specifically about this issue:

http://bugs.gentoo.org/show_bug.cgi?id=79606

Basically, the problem lies in the fact that portage unmerges the previous version _after_ the new version has been merged into place.  One possible solution would be to have a special feature that, when enabled, allows portage to automatically unmerge an old version _before_ the new one is installed (with protection against unmerging system packages of course).

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDvcR8/ejvha5XGaMRAnICAKDyA6xKtGb6mZXxS/mciU91Xvsz8QCeKidL
WRXlWMkvZ7plI2fNPlxO0TA=
=VAP2
-----END PGP SIGNATURE-----
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
>
> > > something like
> > >
> > > if_blocked_by('openmotif')
> > >         ewarn "You must unmerge openmotif before proceeding"
> >
> > Yes, or as follows...
> >
> > if_blocked_by('openmotif')
> >   auto_unmerge('openmotif')
> >   # continue with merge which should automatically be merging openmotif
> > anyhow.
>
> Absolutely not! I don't want portage removing something I may be using at
> the time without my saying so.

Good point.  Perhaps it should ask then?

>
>
> --
> Neil Bothwick
>
> I am in total control, but don't tell my wife.
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/5/06, Richard Fish <bigfish@asmallpond.org> wrote:
> On 1/5/06, Trenton Adams <trenton.d.adams@gmail.com> wrote:
> > Calculating world dependencies |
> > emerge: there are no ebuilds to satisfy ">=dev-perl/PodParser-1.22".
> > (dependency required by "mail-filter/spamassassin-3.1.0" [binary])
>
> This is something that sometimes occurs when you get an out-of-sync
> portage tree (you are syncing at the same time as the mirror is
> updating).

The information in /usr/portage showed the new information, so I don't
*think* that was the case here.

>
> The fix is to just emerge --sync again.
>
> It can also happen if you use NFS for portage but do not keep the
> cache up-to-date.
>
> > re-merge it without --usepkg.  If I recall correctly, I also would
> > have had to remove the file "/var/cache/edb/remote_metadata.pickle",
>
> The portage cache should be updated automatically at the end of every
> sync.  So no, removing this file would not be necessary.

Well for some reason it wasn't.  Hmm, very odd.

>
> > but I started using NFS for my portage instead.  That file has
> > information about packages, and their dependencies, so I looked in it,
> > and it had the wrong information.
>
> Are you also using NFS for /var/cache/edb?  If not, then you need to
> run emerge --metadata.

No, but thanks for pointing that out though.  I'll be sure to update
the metadata next time.

>
> -Richard
>
> PS: Please avoid top-posting here.
>
> --
> gentoo-user@gentoo.org mailing list
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Friday 06 January 2006 06:44, Zac Medico wrote:
>
> version _after_ the new version has been merged into place.  One possible
> solution would be to have a special feature that, when enabled, allows
> portage to automatically unmerge an old version _before_ the new one is
> installed (with protection against unmerging system packages of course).
>
That is no solution AT ALL!!! What if portage unmerges the package and while 
compiling the new package it gets into an error? You are left with no 
installed packages. Even if it is not a system package you can seriously 
screw your system going this way.

Regards,
Abhay

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

On Fri, 6 Jan 2006 12:57:07 +0530, Abhay Kedia wrote:

> > version _after_ the new version has been merged into place.  One
> > possible solution would be to have a special feature that, when
> > enabled, allows portage to automatically unmerge an old version
> > _before_ the new one is installed (with protection against unmerging
> > system packages of course).
> >
> That is no solution AT ALL!!! What if portage unmerges the package and
> while compiling the new package it gets into an error? You are left
> with no installed packages.

Portage could remove the old package after compilation

ebuild package-new.ebuild compile
ebuild package-old.ebuild unmerge
ebuild package-new.ebuild install

This would reduce the chances of something bad happening, but not remove
it altogether. So it would have to package up the old files first and
re-install them if the new install failed, more than a little messy IMO.


-- 
Neil Bothwick

Borg -- James Borg -- licensed to assimilate.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Thu, 05 Jan 2006 17:14:36 -0800, Zac Medico wrote:

> | if_blocked_by('openmotif')
> | 	ewarn "You must unmerge openmotif before proceeding"
> | 
> 
> It would be icky to have to specify blocker logic/messages like that.  

Not in the sort of cases that come up most often, where functionality has
been moved from a package into another. In this case the block is
entirely predictable. If, for example, you are updating xpdf from version
<=X to version >X, it will both require and block poppler. The dev has
already modified the ebuild to handle the new dependency, so he will know
about the block.


-- 
Neil Bothwick

Windows booting: insert CD-ROM 2.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Holly Bostick]

Trenton Adams schreef:
> On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> 
>>On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
>>
>>
>>>>something like
>>>>
>>>>if_blocked_by('openmotif')
>>>>        ewarn "You must unmerge openmotif before proceeding"
>>>
>>>Yes, or as follows...
>>>
>>>if_blocked_by('openmotif')
>>>  auto_unmerge('openmotif')
>>>  # continue with merge which should automatically be merging openmotif
>>>anyhow.
>>
>>Absolutely not! I don't want portage removing something I may be using at
>>the time without my saying so.
> 
> 
> Good point.  Perhaps it should ask then?
> 
> 

Well, it does, by stopping and waiting for you to perform an action and
either restart the stopped process (if the action you took was to
unmerge the blocking package), or to forego the stopped process
entirely,  if you choose not to remove the blocked package because you
want to keep it for whatever reason (it could happen).

You're assuming that unmerging the blocking package is *always* the
right solution for everyone at all times (in this case, it's not really
relevant, since motif-config will itself re-install openmotif), but the
point of Gentoo is that you are in control. If I am in control, then I
have to decide what I want done in each particular situation that
occurs, which is exactly what I have to do with the current setup-- very
obviously, since Portage will stop until I make a decision and act on
it. So fine, your new updated Portage informs me there's a block, and
says, "I could do this to solve it, shall I?" I myself am going to say
"no", because I want to know the nature of the block, and how Portage's
proposed action is going to affect the system that I have carefully
customized to my individual needs.

So I'm right in the same position as I was anyway; the emerge is stopped
(because I said, no don't go on with whatever you plan), and I'm off
reading ChangeLogs and the like to see what's going on in the
environment I'm suddenly dealing with. I suppose that it's all very nice
to have some extra dialog as if Portage was communicating with me more
"humanely", but it's just cosmetic, in actual fact.

Of course, that may be because I take time to read some of the
comprehensive documentation that so many have taken the time to write,
so I know what a Blocked Package is, so it doesn't freak me out when I
come across one. So sue me and call me names... oh wait, you had your
rant already. We'll mark that item "Done", then.

Ultimately, I'm sure such an extra dialog would be a nice thing, but I
don't so much see it as something to get all riled up about. Maybe it's
just me.

Holly


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/6/06, Holly Bostick <motub@planet.nl> wrote:
> Trenton Adams schreef:
> > On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> >
> >>On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
> >>
> >>
> >>>>something like
> >>>>
> >>>>if_blocked_by('openmotif')
> >>>>        ewarn "You must unmerge openmotif before proceeding"
> >>>
> >>>Yes, or as follows...
> >>>
> >>>if_blocked_by('openmotif')
> >>>  auto_unmerge('openmotif')
> >>>  # continue with merge which should automatically be merging openmotif
> >>>anyhow.
> >>
> >>Absolutely not! I don't want portage removing something I may be using at
> >>the time without my saying so.
> >
> >
> > Good point.  Perhaps it should ask then?
> >
> >
>
> Well, it does, by stopping and waiting for you to perform an action and
> either restart the stopped process (if the action you took was to
> unmerge the blocking package), or to forego the stopped process
> entirely,  if you choose not to remove the blocked package because you
> want to keep it for whatever reason (it could happen).
>
> You're assuming that unmerging the blocking package is *always* the
> right solution for everyone at all times (in this case, it's not really
> relevant, since motif-config will itself re-install openmotif), but the
> point of Gentoo is that you are in control. If I am in control, then I
> have to decide what I want done in each particular situation that
> occurs, which is exactly what I have to do with the current setup-- very
> obviously, since Portage will stop until I make a decision and act on
> it. So fine, your new updated Portage informs me there's a block, and
> says, "I could do this to solve it, shall I?" I myself am going to say
> "no", because I want to know the nature of the block, and how Portage's
> proposed action is going to affect the system that I have carefully
> customized to my individual needs.
>
> So I'm right in the same position as I was anyway; the emerge is stopped
> (because I said, no don't go on with whatever you plan), and I'm off
> reading ChangeLogs and the like to see what's going on in the
> environment I'm suddenly dealing with. I suppose that it's all very nice
> to have some extra dialog as if Portage was communicating with me more
> "humanely", but it's just cosmetic, in actual fact.
>
> Of course, that may be because I take time to read some of the
> comprehensive documentation that so many have taken the time to write,
> so I know what a Blocked Package is, so it doesn't freak me out when I
> come across one. So sue me and call me names... oh wait, you had your
> rant already. We'll mark that item "Done", then.

I don't think anyone wants to call you names.  At least not anyone
sensible.  But, I see I struck a nerve on one of my previous posts. 
That's good though, as we *all* need to be provoked to think a little.
 That way we become *wise* rather than *smart*.  And wise is better
than smart. :D

>
> Ultimately, I'm sure such an extra dialog would be a nice thing, but I
> don't so much see it as something to get all riled up about. Maybe it's
> just me.
>
> Holly
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/6/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 05 Jan 2006 17:14:36 -0800, Zac Medico wrote:
>
> > | if_blocked_by('openmotif')
> > |     ewarn "You must unmerge openmotif before proceeding"
> > |
> >
> > It would be icky to have to specify blocker logic/messages like that.
>
> Not in the sort of cases that come up most often, where functionality has
> been moved from a package into another. In this case the block is
> entirely predictable. If, for example, you are updating xpdf from version
> <=X to version >X, it will both require and block poppler. The dev has
> already modified the ebuild to handle the new dependency, so he will know
> about the block.
>

EXACTLY Neil! :)

>
> --
> Neil Bothwick
>
> Windows booting: insert CD-ROM 2.
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

Oops, forgot to reply to everything.

On 1/6/06, Holly Bostick <motub@planet.nl> wrote:
> Trenton Adams schreef:
> > On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> >
> >>On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
> >>
> >>
> >>>>something like
> >>>>
> >>>>if_blocked_by('openmotif')
> >>>>        ewarn "You must unmerge openmotif before proceeding"
> >>>
> >>>Yes, or as follows...
> >>>
> >>>if_blocked_by('openmotif')
> >>>  auto_unmerge('openmotif')
> >>>  # continue with merge which should automatically be merging openmotif
> >>>anyhow.
> >>
> >>Absolutely not! I don't want portage removing something I may be using at
> >>the time without my saying so.
> >
> >
> > Good point.  Perhaps it should ask then?
> >
> >
>
> Well, it does, by stopping and waiting for you to perform an action and
> either restart the stopped process (if the action you took was to
> unmerge the blocking package), or to forego the stopped process
> entirely,  if you choose not to remove the blocked package because you
> want to keep it for whatever reason (it could happen).
>
> You're assuming that unmerging the blocking package is *always* the
> right solution for everyone at all times (in this case, it's not really
> relevant, since motif-config will itself re-install openmotif), but the
> point of Gentoo is that you are in control. If I am in control, then I
> have to decide what I want done in each particular situation that
> occurs, which is exactly what I have to do with the current setup-- very
> obviously, since Portage will stop until I make a decision and act on
> it. So fine, your new updated Portage informs me there's a block, and
> says, "I could do this to solve it, shall I?" I myself am going to say
> "no", because I want to know the nature of the block, and how Portage's
> proposed action is going to affect the system that I have carefully
> customized to my individual needs.

Yes, flexibility is GREAT.  That's one reason I really like gentoo,
and linux in general.  However, I also like simplicity, or should I
say, I like to have the choice.  So, one could easily make gentoo have
auto-detect and handle features, while allowing configuration changes
that disable automatic behaviour.  You could have individual
enable/disable options for each feature, as well as one global feature
than enables/disables all auto-detect features.  Then you could have
include/excludes for each feature so that the global would not
override them.

So, the bottom line is this, one person says that things are difficult
because they need to be, in order to be flexible.  But I say that if
things are truly flexible, then it should also be possible to make
them automatic, or simple.  That's what I call ULTIMATE flexiblity,
which is what I mentioned in another post that I made.  When I
originally started with gentoo linux, I read the part about why gentoo
linux came about.  Basically it was all about doing things the way you
want.  Well, I like the flexiblity, but I also want the simplicity. :)
 Let us have the simplicity of RedHat, and RPMs (waiting for flames),
but with flexibility as well.

I understand that gentoo is a work in progress, and will probably
remain that way forever (I HOPE).  So, any ideas should at least be
analyzed, and thought out, and not just discarded.

>
> So I'm right in the same position as I was anyway; the emerge is stopped
> (because I said, no don't go on with whatever you plan), and I'm off
> reading ChangeLogs and the like to see what's going on in the
> environment I'm suddenly dealing with. I suppose that it's all very nice
> to have some extra dialog as if Portage was communicating with me more
> "humanely", but it's just cosmetic, in actual fact.
>
> Of course, that may be because I take time to read some of the
> comprehensive documentation that so many have taken the time to write,
> so I know what a Blocked Package is, so it doesn't freak me out when I
> come across one. So sue me and call me names... oh wait, you had your
> rant already. We'll mark that item "Done", then.
>
> Ultimately, I'm sure such an extra dialog would be a nice thing, but I
> don't so much see it as something to get all riled up about. Maybe it's
> just me.
>
> Holly
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Holly Bostick]

Trenton Adams schreef:
> Oops, forgot to reply to everything.
> 
> On 1/6/06, Holly Bostick <motub@planet.nl> wrote:
> 
>> Trenton Adams schreef:
>> 
>>> On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
>>> 
>>> 
>>>> On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
>>>> 
>>>> 
>>>> 
>>>>>> something like
>>>>>> 
>>>>>> if_blocked_by('openmotif') ewarn "You must unmerge
>>>>>> openmotif before proceeding"
>>>>> 
>>>>> Yes, or as follows...
>>>>> 
>>>>> if_blocked_by('openmotif') auto_unmerge('openmotif') #
>>>>> continue with merge which should automatically be merging
>>>>> openmotif anyhow.
>>>> 
>>>> Absolutely not! I don't want portage removing something I may
>>>> be using at the time without my saying so.
>>> 
>>> 
>>> Good point.  Perhaps it should ask then?
>>> 
>>> 
>> 
>> Well, it does, by stopping and waiting for you to perform an action
>> and either restart the stopped process (if the action you took was
>> to unmerge the blocking package), or to forego the stopped process 
>> entirely,  if you choose not to remove the blocked package because
>> you want to keep it for whatever reason (it could happen).
>> 
>> You're assuming that unmerging the blocking package is *always* the
>>  right solution for everyone at all times (in this case, it's not
>> really relevant, since motif-config will itself re-install
>> openmotif), but the point of Gentoo is that you are in control. If
>> I am in control, then I have to decide what I want done in each
>> particular situation that occurs, which is exactly what I have to
>> do with the current setup-- very obviously, since Portage will stop
>> until I make a decision and act on it. So fine, your new updated
>> Portage informs me there's a block, and says, "I could do this to
>> solve it, shall I?" I myself am going to say "no", because I want
>> to know the nature of the block, and how Portage's proposed action
>> is going to affect the system that I have carefully customized to
>> my individual needs.
> 
> 
> Yes, flexibility is GREAT.  That's one reason I really like gentoo, 
> and linux in general.  However, I also like simplicity, or should I 
> say, I like to have the choice.  So, one could easily make gentoo
> have auto-detect and handle features, while allowing configuration
> changes that disable automatic behaviour.  You could have individual 
> enable/disable options for each feature, as well as one global
> feature than enables/disables all auto-detect features.  Then you
> could have include/excludes for each feature so that the global would
> not override them.
> 
> So, the bottom line is this, one person says that things are
> difficult because they need to be, in order to be flexible.  But I
> say that if things are truly flexible, then it should also be
> possible to make them automatic, or simple.  That's what I call
> ULTIMATE flexiblity, which is what I mentioned in another post that I
> made.  When I originally started with gentoo linux, I read the part
> about why gentoo linux came about.  Basically it was all about doing
> things the way you want.  Well, I like the flexiblity, but I also
> want the simplicity. :) Let us have the simplicity of RedHat, and
> RPMs (waiting for flames), but with flexibility as well.

Well, if this is your opinion, I must then accept the burden of being
one of those members of the Linux community you mention

Trenton Adams schreef:

> Yes, and I've noticed there's a big problem with the linux community 
> at large.  People that know and understand linux have a lot of the 
> times not helped the "open source" intiative, in that they like
> things to be difficult,

Although this is not strictly true.... I don't *like* things to be
difficult, /per se/ but I do tend to do things "the hard way" rather
than "the easy way"

> because it makes them somehow seem smarter.  In all reality, it
> doesn't take a genius to use linux, just someone who likes to read a
> whole lot.

I do like to read a whole lot (always have), and I don't so much care
how smart anyone thinks I am, but if I am in any way smart, I do want
that to be recognized, which is a different thing.

But if you leave out the rather insulting insinuation that such users
are not in fact smart, but ego-trippers who just have nothing to do but
read dry technical texts that no "normal" person would ever bother with,
I'll cop to the charge.

The thing is, I prefer things to be slightly more difficult because I
believe that people using advanced tools should have a clue about how
they work and how to use them properly.

As I have said before, and will likely say again in the future, I
believe that a policy of providing advanced technology, dumbed-down so
that it "Just Works" to the "unwashed masses" (let us say, my
boyfriend's grandmother, who is a very nice lady, or my aunt, or his
mother, who are of an age and about the same level of computer expertise
and interest-- which is to say, "none", although my bf's mother has now
had a computer forced on her), is dangerously unwise.

We have seen the results of doing so in both large and small ways, yet
we persist. I believe that advanced technology should be sufficiently
difficult to use until such time as it is "safe" (if it ever is) that
people who don't want to think at all won't use it, to be frank. Because
I don't want someone who doesn't want to think to be in control of
advanced technology or tools whose misuse may well impact me (these are
"advanced tools", after all, and that is one of the qualities that makes
them "advanced"-- a wide range of impact), even if I never know that
person, and never will.

At least I know me, and at least if I rain destruction on my PC and my
network, it's my own fault. I'm willing to take responsibility for that.
I'm not willing to trust faceless developers at RedHat (or SuSE/Novell,
or even Mandriva) with these responsibilities. On the other hand, I am
willing to trust the Gentoo devs to a much greater degree, because 1)
they *share* their knowledge freely (so I know what they're doing, if I
can understand it); 2) they welcome my contribution/participation in
what they are doing, in fact recommend it; and most importantly, 3) they
draw and respect boundaries, beyond which I am expected to take
responsibility for myself... which is how a good parent/administrator
trains children/"average users" to become competent and knowledgeable
adults/users.

Something I've always remembered is that when I was learning to drive,
the Department of Motor Vehicles required that all proposed licensees
had to take this class where we watched a film about the evils of
drinking and driving I think it was. In any case, the instructor said,
"Most people on the road are not /drivers/. They are /operators of
vehicles/." The difference being that operators of vehicles can get the
vehicle from Point A to Point B, but don't really understand much about
the complex interaction between the advanced technological tool they are
operating (which they likely also know little about), the environment
they are operating in, where other advanced technological tools are also
operating, the impact of their operation on the (possibly incompetent)
opertation of the others in the environment, and how the environment
itself has been shaped specifically to make managing the interaction of
all these elements and various random, unpredictable variables as smooth
as possible, so that the goal can be reached-- all of which a driver
would/must have a greater sense of. He proposed to set us on the path to
being drivers, rather than operators of vehicles.

Gentoo has a similar philosophy in the computer field. I can get your
point about "ULTIMATE flexibility", but in the real world, in many
fields, you are supposed to learn the hard way (learn the rules first)
before you may take the easy way (break the rules), if you then choose
to do so. And we all know that "most people", offered the choice of an
easy way and a hard way are going to take the easy way *all the time*,
and thus flail around in relative ignorance for the rest of their days.

Which is exactly what I'm against-- ignorance. No, I don't want Gentoo
to be all that "easy". But not because I want to put myself up as better
than anybody-- I'm not in fact better than anybody. $DEITY knows, Neil
knows way more than me, and even he makes mistakes :-) . But you can't
learn if you don't try, and you can't try if you don't get the chance
(because everything is so "easy" that you never have the opportunity).

And I want to learn. I don't want to be ignorant. And I don't want
Gentoo to "do it for me" until I know enough to know what letting it do
so means-- at which point letting it do it for me is completely
irrelevant (though possibly convienient in some situations), since by
that time I know enough that what it's going to automatically could be
done manually by me in the same amount of or possibly less time.

So I am of the opinion that, as I said before, this is a cosmetic issue.
If the devs have time to code a tool that will give more comprehensive
output about the nature of any given block, and propose solutions that I
can choose to accept or not, that's all very nice, as I said.

But the X amount of time that it takes them to do that is about the same
X amount of time that it takes me to just look the information up myself
(the time it takes me to decide is unchanged, since I have to do that
either way), and frankly, I'd rather that the devs spent that X amount
of time doing something more substantive to enhancing my Gentoo experience.

Maybe it's just me.

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Saturday 07 January 2006 10:43, Trenton Adams wrote:
>
> which is what I mentioned in another post that I made.  When I
> originally started with gentoo linux, I read the part about why gentoo
> linux came about.  Basically it was all about doing things the way you
> want.  Well, I like the flexiblity, but I also want the simplicity. :)
>  Let us have the simplicity of RedHat, and RPMs (waiting for flames),
> but with flexibility as well.
>
You should review what you want out of your Linux Distro cos I for once am 
failing to understand your point of view. What do you want? Gentoo is gentoo. 
It gives you full control to do what *YOU* want to do and taking full control 
of a full fledged OS is needless to say; "difficult". If you don't desire or 
need the full control then imho there are various other distros available 
with *simplicity* written all over them. They should be there at your 
service. But if Gentoo starts to uninstall stuff from my system without 
asking me then the whole philosophy of control dies or Gentoo dies.

Regards,
Abhay

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/7/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> On Saturday 07 January 2006 10:43, Trenton Adams wrote:
> >
> > which is what I mentioned in another post that I made.  When I
> > originally started with gentoo linux, I read the part about why gentoo
> > linux came about.  Basically it was all about doing things the way you
> > want.  Well, I like the flexiblity, but I also want the simplicity. :)
> >  Let us have the simplicity of RedHat, and RPMs (waiting for flames),
> > but with flexibility as well.
> >
> You should review what you want out of your Linux Distro cos I for once am
> failing to understand your point of view. What do you want? Gentoo is gentoo.
> It gives you full control to do what *YOU* want to do and taking full control
> of a full fledged OS is needless to say; "difficult". If you don't desire or
> need the full control then imho there are various other distros available
> with *simplicity* written all over them. They should be there at your
> service. But if Gentoo starts to uninstall stuff from my system without
> asking me then the whole philosophy of control dies or Gentoo dies.

I never said it should uninstall stuff without asking you.  In fact, I
suggested it ask me.  And gentoo is hardly "difficult" for anyone with
a brain.  *Perhaps* time consuming to learn, but not "difficult".  And
as I said before, I'm using gentoo because of it's flexibility, so
that's what I'm sticking with.  In fact, all my Linux computers have
now been converted to gentoo, as of this past week.  So I don't plan
on switching them back any time soon.  I'm just of the mind that we
really should encourage it's use, while encouraging people to also
understand what's happening under the hood.  I like both that my car
just works, and I don't have to know how the pistons go up and down,
but that I can also look under the hood if I so desire.

>
> Regards,
> Abhay
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

Interesting viewpoint, and some of the things you say do have
relevance Holly.  Thanks.  But, I still think things should be a
little easier for the average user.  I'm really sick of the windows
admins who *think* linux is hard, when it's really not, and bash it
all the time because of that.  I'm all for converting them. :)

On 1/7/06, Holly Bostick <motub@planet.nl> wrote:
> Trenton Adams schreef:
> > Oops, forgot to reply to everything.
> >
> > On 1/6/06, Holly Bostick <motub@planet.nl> wrote:
> >
> >> Trenton Adams schreef:
> >>
> >>> On 1/5/06, Neil Bothwick <neil@digimed.co.uk> wrote:
> >>>
> >>>
> >>>> On Thu, 5 Jan 2006 16:32:20 -0700, Trenton Adams wrote:
> >>>>
> >>>>
> >>>>
> >>>>>> something like
> >>>>>>
> >>>>>> if_blocked_by('openmotif') ewarn "You must unmerge
> >>>>>> openmotif before proceeding"
> >>>>>
> >>>>> Yes, or as follows...
> >>>>>
> >>>>> if_blocked_by('openmotif') auto_unmerge('openmotif') #
> >>>>> continue with merge which should automatically be merging
> >>>>> openmotif anyhow.
> >>>>
> >>>> Absolutely not! I don't want portage removing something I may
> >>>> be using at the time without my saying so.
> >>>
> >>>
> >>> Good point.  Perhaps it should ask then?
> >>>
> >>>
> >>
> >> Well, it does, by stopping and waiting for you to perform an action
> >> and either restart the stopped process (if the action you took was
> >> to unmerge the blocking package), or to forego the stopped process
> >> entirely,  if you choose not to remove the blocked package because
> >> you want to keep it for whatever reason (it could happen).
> >>
> >> You're assuming that unmerging the blocking package is *always* the
> >>  right solution for everyone at all times (in this case, it's not
> >> really relevant, since motif-config will itself re-install
> >> openmotif), but the point of Gentoo is that you are in control. If
> >> I am in control, then I have to decide what I want done in each
> >> particular situation that occurs, which is exactly what I have to
> >> do with the current setup-- very obviously, since Portage will stop
> >> until I make a decision and act on it. So fine, your new updated
> >> Portage informs me there's a block, and says, "I could do this to
> >> solve it, shall I?" I myself am going to say "no", because I want
> >> to know the nature of the block, and how Portage's proposed action
> >> is going to affect the system that I have carefully customized to
> >> my individual needs.
> >
> >
> > Yes, flexibility is GREAT.  That's one reason I really like gentoo,
> > and linux in general.  However, I also like simplicity, or should I
> > say, I like to have the choice.  So, one could easily make gentoo
> > have auto-detect and handle features, while allowing configuration
> > changes that disable automatic behaviour.  You could have individual
> > enable/disable options for each feature, as well as one global
> > feature than enables/disables all auto-detect features.  Then you
> > could have include/excludes for each feature so that the global would
> > not override them.
> >
> > So, the bottom line is this, one person says that things are
> > difficult because they need to be, in order to be flexible.  But I
> > say that if things are truly flexible, then it should also be
> > possible to make them automatic, or simple.  That's what I call
> > ULTIMATE flexiblity, which is what I mentioned in another post that I
> > made.  When I originally started with gentoo linux, I read the part
> > about why gentoo linux came about.  Basically it was all about doing
> > things the way you want.  Well, I like the flexiblity, but I also
> > want the simplicity. :) Let us have the simplicity of RedHat, and
> > RPMs (waiting for flames), but with flexibility as well.
>
> Well, if this is your opinion, I must then accept the burden of being
> one of those members of the Linux community you mention
>
> Trenton Adams schreef:
>
> > Yes, and I've noticed there's a big problem with the linux community
> > at large.  People that know and understand linux have a lot of the
> > times not helped the "open source" intiative, in that they like
> > things to be difficult,
>
> Although this is not strictly true.... I don't *like* things to be
> difficult, /per se/ but I do tend to do things "the hard way" rather
> than "the easy way"
>
> > because it makes them somehow seem smarter.  In all reality, it
> > doesn't take a genius to use linux, just someone who likes to read a
> > whole lot.
>
> I do like to read a whole lot (always have), and I don't so much care
> how smart anyone thinks I am, but if I am in any way smart, I do want
> that to be recognized, which is a different thing.
>
> But if you leave out the rather insulting insinuation that such users
> are not in fact smart, but ego-trippers who just have nothing to do but
> read dry technical texts that no "normal" person would ever bother with,
> I'll cop to the charge.
>
> The thing is, I prefer things to be slightly more difficult because I
> believe that people using advanced tools should have a clue about how
> they work and how to use them properly.
>
> As I have said before, and will likely say again in the future, I
> believe that a policy of providing advanced technology, dumbed-down so
> that it "Just Works" to the "unwashed masses" (let us say, my
> boyfriend's grandmother, who is a very nice lady, or my aunt, or his
> mother, who are of an age and about the same level of computer expertise
> and interest-- which is to say, "none", although my bf's mother has now
> had a computer forced on her), is dangerously unwise.
>
> We have seen the results of doing so in both large and small ways, yet
> we persist. I believe that advanced technology should be sufficiently
> difficult to use until such time as it is "safe" (if it ever is) that
> people who don't want to think at all won't use it, to be frank. Because
> I don't want someone who doesn't want to think to be in control of
> advanced technology or tools whose misuse may well impact me (these are
> "advanced tools", after all, and that is one of the qualities that makes
> them "advanced"-- a wide range of impact), even if I never know that
> person, and never will.
>
> At least I know me, and at least if I rain destruction on my PC and my
> network, it's my own fault. I'm willing to take responsibility for that.
> I'm not willing to trust faceless developers at RedHat (or SuSE/Novell,
> or even Mandriva) with these responsibilities. On the other hand, I am
> willing to trust the Gentoo devs to a much greater degree, because 1)
> they *share* their knowledge freely (so I know what they're doing, if I
> can understand it); 2) they welcome my contribution/participation in
> what they are doing, in fact recommend it; and most importantly, 3) they
> draw and respect boundaries, beyond which I am expected to take
> responsibility for myself... which is how a good parent/administrator
> trains children/"average users" to become competent and knowledgeable
> adults/users.
>
> Something I've always remembered is that when I was learning to drive,
> the Department of Motor Vehicles required that all proposed licensees
> had to take this class where we watched a film about the evils of
> drinking and driving I think it was. In any case, the instructor said,
> "Most people on the road are not /drivers/. They are /operators of
> vehicles/." The difference being that operators of vehicles can get the
> vehicle from Point A to Point B, but don't really understand much about
> the complex interaction between the advanced technological tool they are
> operating (which they likely also know little about), the environment
> they are operating in, where other advanced technological tools are also
> operating, the impact of their operation on the (possibly incompetent)
> opertation of the others in the environment, and how the environment
> itself has been shaped specifically to make managing the interaction of
> all these elements and various random, unpredictable variables as smooth
> as possible, so that the goal can be reached-- all of which a driver
> would/must have a greater sense of. He proposed to set us on the path to
> being drivers, rather than operators of vehicles.
>
> Gentoo has a similar philosophy in the computer field. I can get your
> point about "ULTIMATE flexibility", but in the real world, in many
> fields, you are supposed to learn the hard way (learn the rules first)
> before you may take the easy way (break the rules), if you then choose
> to do so. And we all know that "most people", offered the choice of an
> easy way and a hard way are going to take the easy way *all the time*,
> and thus flail around in relative ignorance for the rest of their days.
>
> Which is exactly what I'm against-- ignorance. No, I don't want Gentoo
> to be all that "easy". But not because I want to put myself up as better
> than anybody-- I'm not in fact better than anybody. $DEITY knows, Neil
> knows way more than me, and even he makes mistakes :-) . But you can't
> learn if you don't try, and you can't try if you don't get the chance
> (because everything is so "easy" that you never have the opportunity).
>
> And I want to learn. I don't want to be ignorant. And I don't want
> Gentoo to "do it for me" until I know enough to know what letting it do
> so means-- at which point letting it do it for me is completely
> irrelevant (though possibly convienient in some situations), since by
> that time I know enough that what it's going to automatically could be
> done manually by me in the same amount of or possibly less time.
>
> So I am of the opinion that, as I said before, this is a cosmetic issue.
> If the devs have time to code a tool that will give more comprehensive
> output about the nature of any given block, and propose solutions that I
> can choose to accept or not, that's all very nice, as I said.
>
> But the X amount of time that it takes them to do that is about the same
> X amount of time that it takes me to just look the information up myself
> (the time it takes me to decide is unchanged, since I have to do that
> either way), and frankly, I'd rather that the devs spent that X amount
> of time doing something more substantive to enhancing my Gentoo experience.
>
> Maybe it's just me.
>
> Holly
> --
> gentoo-user@gentoo.org mailing list
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]

On Saturday 07 January 2006 22:00, Trenton Adams wrote:
>
> I'm just of the mind that we really should encourage it's use, while 
> encouraging people to also understand what's happening under the
> hood. 
>
...and how do you suggest that should be done? There is tons of documentation 
available for user to read and know what is happening under the hood but no 
one wants to RTFM. Even this problem that you faced has been clearly 
explained along with its solution in "man emerge". How should Gentoo force a 
user to read the documentation and the man pages?

>
> I like both that my car just works, and I don't have to know how the
> pistons go up and down, but that I can also look under the hood if I so 
> desire. 
>
Thinking on the wrong lines again and what you want can never happen, at least 
with Gentoo; because Gentoo does not give you a working car at all. It just 
gives you spare parts (ebuilds & packages), books to read (documentation) and 
a tool box (portage). Then it tells you to go ahead and make your own car. It 
totally depends on you whether you want to make it a blazing fast Ferrari or 
a classy Limo. To achieve anything of that sorts you *HAVE TO* know how the 
pistons go up and down. If you don't read and just put together the pieces in 
a random order then you might make a moving car but it will not be a working 
one. Moral of the story? To have full control, you gotta know how things work 
inside the engine :)

Regards,
Abhay

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Trenton Adams]

Interesting points, but

On 1/7/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> On Saturday 07 January 2006 22:00, Trenton Adams wrote:
> >
> > I'm just of the mind that we really should encourage it's use, while
> > encouraging people to also understand what's happening under the
> > hood.
> >
> ...and how do you suggest that should be done? There is tons of documentation
> available for user to read and know what is happening under the hood but no
> one wants to RTFM. Even this problem that you faced has been clearly
> explained along with its solution in "man emerge". How should Gentoo force a
> user to read the documentation and the man pages?

So, there's documentation that specifically explains that packages can
be split, and this can cause a conflict?  I tried to find that, after
I resolved the problem, but to no avail.  There is documentation on
conflicts in general.

Besides, this problem I ran into wasn't much of a problem, as I was
able to figure it out quite easily without documentation.  Personally,
I dont' need most of gentoo's documentation, as I've found it quite
easy to use, after learning and reading about a few basic things.  But
not everyone does.

>
> >
> > I like both that my car just works, and I don't have to know how the
> > pistons go up and down, but that I can also look under the hood if I so
> > desire.
> >
> Thinking on the wrong lines again and what you want can never happen, at least
> with Gentoo; because Gentoo does not give you a working car at all. It just
> gives you spare parts (ebuilds & packages), books to read (documentation) and
> a tool box (portage). Then it tells you to go ahead and make your own car. It
> totally depends on you whether you want to make it a blazing fast Ferrari or
> a classy Limo. To achieve anything of that sorts you *HAVE TO* know how the
> pistons go up and down. If you don't read and just put together the pieces in
> a random order then you might make a moving car but it will not be a working
> one. Moral of the story? To have full control, you gotta know how things work
> inside the engine :)

Well actually, it could happen.  If I had a menu of packages to be
installed during some sort of automated install process, then I'm
still customizing my system the way I want.  So once again, you
absolutely *CAN* have gentoo flexibility with easy of install, as an
example.  I never was referring to install, but that could be cleaned
up too. :)  You can think of this like a robotics assembly line that
will make anything that your heart desires FOR YOU.  Then, you can go
and look at the technical manuals to find out what happened.

>
> Regards,
> Abhay
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Holly Bostick]

Trenton Adams schreef:
> Interesting points, but
> 
> On 1/7/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> 
>> On Saturday 07 January 2006 22:00, Trenton Adams wrote:
>> 
>>> I like both that my car just works, and I don't have to know how 
>>> the pistons go up and down, but that I can also look under the 
>>> hood if I so desire.
>>> 
>> 
>> Thinking on the wrong lines again and what you want can never 
>> happen, at least with Gentoo; because Gentoo does not give you a 
>> working car at all. It just gives you spare parts (ebuilds & 
>> packages), books to read (documentation) and a tool box (portage). 
>> Then it tells you to go ahead and make your own car. It totally 
>> depends on you whether you want to make it a blazing fast Ferrari 
>> or a classy Limo. To achieve anything of that sorts you *HAVE TO* 
>> know how the pistons go up and down. If you don't read and just put
>>  together the pieces in a random order then you might make a moving
>>  car but it will not be a working one. Moral of the story? To have 
>> full control, you gotta know how things work inside the engine :)
> 
> 
> Well actually, it could happen.  If I had a menu of packages to be 
> installed during some sort of automated install process, then I'm 
> still customizing my system the way I want.  So once again, you 
> absolutely *CAN* have gentoo flexibility with easy of install

Just a quick question:

Isn't creating "a menu of packages to be installed" part of the install
process?

If not, because you did not create this menu yourself, then you are not
"customizing your system the way you want", but rather choosing the most
suitable for you amongst a list of pre-defined-- thus, by definition,
limiting-- options.

If you did create the menu of packages yourself, and it then is (as it
must be) considered part of the installation process, then isn't the
installation process no longer "easy", by your definition of "easy"?

Not quite following the logic here.

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

First off all, the install process is only a portion of making gentoo
*easier*.  At it is kind of a tangent to the original discussion. 
But, none the less, it is a good discussion.

On 1/7/06, Holly Bostick <motub@planet.nl> wrote:
> Trenton Adams schreef:
> > Interesting points, but
> >
> > On 1/7/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> >
> >> On Saturday 07 January 2006 22:00, Trenton Adams wrote:
> >>
> >>> I like both that my car just works, and I don't have to know how
> >>> the pistons go up and down, but that I can also look under the
> >>> hood if I so desire.
> >>>
> >>
> >> Thinking on the wrong lines again and what you want can never
> >> happen, at least with Gentoo; because Gentoo does not give you a
> >> working car at all. It just gives you spare parts (ebuilds &
> >> packages), books to read (documentation) and a tool box (portage).
> >> Then it tells you to go ahead and make your own car. It totally
> >> depends on you whether you want to make it a blazing fast Ferrari
> >> or a classy Limo. To achieve anything of that sorts you *HAVE TO*
> >> know how the pistons go up and down. If you don't read and just put
> >>  together the pieces in a random order then you might make a moving
> >>  car but it will not be a working one. Moral of the story? To have
> >> full control, you gotta know how things work inside the engine :)
> >
> >
> > Well actually, it could happen.  If I had a menu of packages to be
> > installed during some sort of automated install process, then I'm
> > still customizing my system the way I want.  So once again, you
> > absolutely *CAN* have gentoo flexibility with easy of install
>
> Just a quick question:
>
> Isn't creating "a menu of packages to be installed" part of the install
> process?
>
> If not, because you did not create this menu yourself, then you are not
> "customizing your system the way you want", but rather choosing the most
> suitable for you amongst a list of pre-defined-- thus, by definition,
> limiting-- options.

Here we go again, who says that you have to limit it to a menu?  Give
a menu, but allow a graphical shell during install for those that want
to do extra packages, or whatever.  Or, even provide a dynamically
extendable menu that can grab packages lists from other places, from
another CD, floppy, Internet, etc.  So, to not provide a menu would be
*limiting* as well.  But I do agree with you Holly, that providing
*only* a *predefined* graphical menu for package installation would be
limiting.

Now, I'm just brain storming here...

Wouldn't it be beneficial to provide automated graphical installs for
gentoo, but provide the option to open a graphical shell at *all*
stages of the installation process?  Wouldn't that be ultimate
flexibility?  I read about the new graphical install for gentoo, and
perhaps it already does this!?!?

>
> If you did create the menu of packages yourself, and it then is (as it
> must be) considered part of the installation process, then isn't the
> installation process no longer "easy", by your definition of "easy"?

Well, this is a side tangent, given my reply just above.  None the
less, all of *my* installs from the point after I created my *own*
menu would be easy.

>
> Not quite following the logic here.
>
> Holly
> --
> gentoo-user@gentoo.org mailing list
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

Sorry, I shouldn't have said, "Here we go again", as that can be
antogonizing, which doesn't help anything. :(

On 1/7/06, Trenton Adams <trenton.d.adams@gmail.com> wrote:
> First off all, the install process is only a portion of making gentoo
> *easier*.  At it is kind of a tangent to the original discussion.
> But, none the less, it is a good discussion.
>
> On 1/7/06, Holly Bostick <motub@planet.nl> wrote:
> > Trenton Adams schreef:
> > > Interesting points, but
> > >
> > > On 1/7/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> > >
> > >> On Saturday 07 January 2006 22:00, Trenton Adams wrote:
> > >>
> > >>> I like both that my car just works, and I don't have to know how
> > >>> the pistons go up and down, but that I can also look under the
> > >>> hood if I so desire.
> > >>>
> > >>
> > >> Thinking on the wrong lines again and what you want can never
> > >> happen, at least with Gentoo; because Gentoo does not give you a
> > >> working car at all. It just gives you spare parts (ebuilds &
> > >> packages), books to read (documentation) and a tool box (portage).
> > >> Then it tells you to go ahead and make your own car. It totally
> > >> depends on you whether you want to make it a blazing fast Ferrari
> > >> or a classy Limo. To achieve anything of that sorts you *HAVE TO*
> > >> know how the pistons go up and down. If you don't read and just put
> > >>  together the pieces in a random order then you might make a moving
> > >>  car but it will not be a working one. Moral of the story? To have
> > >> full control, you gotta know how things work inside the engine :)
> > >
> > >
> > > Well actually, it could happen.  If I had a menu of packages to be
> > > installed during some sort of automated install process, then I'm
> > > still customizing my system the way I want.  So once again, you
> > > absolutely *CAN* have gentoo flexibility with easy of install
> >
> > Just a quick question:
> >
> > Isn't creating "a menu of packages to be installed" part of the install
> > process?
> >
> > If not, because you did not create this menu yourself, then you are not
> > "customizing your system the way you want", but rather choosing the most
> > suitable for you amongst a list of pre-defined-- thus, by definition,
> > limiting-- options.
>
> Here we go again, who says that you have to limit it to a menu?  Give
> a menu, but allow a graphical shell during install for those that want
> to do extra packages, or whatever.  Or, even provide a dynamically
> extendable menu that can grab packages lists from other places, from
> another CD, floppy, Internet, etc.  So, to not provide a menu would be
> *limiting* as well.  But I do agree with you Holly, that providing
> *only* a *predefined* graphical menu for package installation would be
> limiting.
>
> Now, I'm just brain storming here...
>
> Wouldn't it be beneficial to provide automated graphical installs for
> gentoo, but provide the option to open a graphical shell at *all*
> stages of the installation process?  Wouldn't that be ultimate
> flexibility?  I read about the new graphical install for gentoo, and
> perhaps it already does this!?!?
>
> >
> > If you did create the menu of packages yourself, and it then is (as it
> > must be) considered part of the installation process, then isn't the
> > installation process no longer "easy", by your definition of "easy"?
>
> Well, this is a side tangent, given my reply just above.  None the
> less, all of *my* installs from the point after I created my *own*
> menu would be easy.
>
> >
> > Not quite following the logic here.
> >
> > Holly
> > --
> > gentoo-user@gentoo.org mailing list
> >
> >
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

On Sunday 08 January 2006 03:25, Trenton Adams wrote:
>
> So, there's documentation that specifically explains that packages can
> be split, and this can cause a conflict?  I tried to find that, after
>
What? How is packages being split even comes in question and why does it need 
"specific" documentation? A conflict is a conflict. It can arise because of 
any new change that has been committed to portage. Man pages explain how to 
solve these conflicts. Job done!

Now I don't understand how hand-picking each problem and then explaining about 
it is going to help. Documentation about a super-set is present. How will 
writing the same thing about each subset help the matter? If anything it will 
just increase the redundancy. What you want is a how to on climbing the 
stairs. Either you can write, "Climb 1st step and then go step by step" or 
you can write "Climb 1st step, then climb 2nd step, then 3rd step, then 
climb..."? Which one do you want?

>
> I dont' need most of gentoo's documentation, as I've found it quite
> easy to use, after learning and reading about a few basic things.  But
> not everyone does.
>
Why? Why doesn't everyone else find Gentoo easy? What is it that differs you 
from others? Some super intelligence? The only difference between you and the 
others that I can see is that you chose to read while others don't.

Regards,
Abhay

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

On Sunday 08 January 2006 06:36, Trenton Adams wrote:
>
> Here we go again, who says that you have to limit it to a menu?  Give
> a menu, but allow a graphical shell during install for those that want
> to do extra packages, or whatever.  Or, even provide a dynamically
> extendable menu that can grab packages lists from other places, from
> another CD, floppy, Internet, etc.  So, to not provide a menu would be
> *limiting* as well.  But I do agree with you Holly, that providing
> *only* a *predefined* graphical menu for package installation would be
> limiting.
>
Menu of what? How will a Gentoo developer know what you want to install? If 
you are starting from Stage 3, you just need to choose what to install and 
thats it. How will a menu help you in that? As far as graphics based Gentoo 
install is concerned. I don't think that it is even anywhere near Gentoo 
Dev's priorities right now.

>
> Wouldn't it be beneficial to provide automated graphical installs for
> gentoo, but provide the option to open a graphical shell at *all*
> stages of the installation process?  Wouldn't that be ultimate
> flexibility?  I read about the new graphical install for gentoo, and
> perhaps it already does this!?!?
>
Yes having a graphical install process would be great. Why don't you volunteer 
and try to write one for us? :)

Regards,
Abhay

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/8/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> On Sunday 08 January 2006 03:25, Trenton Adams wrote:
> >
> > So, there's documentation that specifically explains that packages can
> > be split, and this can cause a conflict?  I tried to find that, after
> >
> What? How is packages being split even comes in question and why does it need
> "specific" documentation? A conflict is a conflict. It can arise because of
> any new change that has been committed to portage. Man pages explain how to
> solve these conflicts. Job done!
>
> Now I don't understand how hand-picking each problem and then explaining about
> it is going to help. Documentation about a super-set is present. How will
> writing the same thing about each subset help the matter? If anything it will
> just increase the redundancy. What you want is a how to on climbing the
> stairs. Either you can write, "Climb 1st step and then go step by step" or
> you can write "Climb 1st step, then climb 2nd step, then 3rd step, then
> climb..."? Which one do you want?
>
> >
> > I dont' need most of gentoo's documentation, as I've found it quite
> > easy to use, after learning and reading about a few basic things.  But
> > not everyone does.
> >
> Why? Why doesn't everyone else find Gentoo easy? What is it that differs you
> from others? Some super intelligence? The only difference between you and the
> others that I can see is that you chose to read while others don't.

Well, could be many things.  I've found fear of computers to be one
blocker to being better at computers than one can be.  Having fear
creates a mind block.  Another one could simply be lack of experience.
 The more experience you have, the more likely you are able to solve a
*new* problem quickly, as it could be related in some way.  Perhaps
you can call this intuition.  And I'm sure there are many more.

So no, not superior intelligence.  In fact, I don't believe in
*genius*. :)  Actually, I had a great debate about this topic with a
guy at work.  He worships people like Linus and such.  I told him that
even people like Linus, although intelligent, will happily admit that
they are products of circumstance.  And, to prove my point, I did a
search about Linus on this topic.  As it were, he wrote a book called
"The Accidental Revolutionary", or something like that.  I've actually
been meaning to read it.  So, either Linus has false humility (which
is arrogance), or he means what he says.  I've also found that those
who think they are intelligent, usually are not. :D  As it were, I
believe Linus to actually be intelligent, only because he decides to
actually work, rather than sit on his butt all day.  But, that's all a
side tangent. LOL

>
> Regards,
> Abhay
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/8/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> On Sunday 08 January 2006 06:36, Trenton Adams wrote:
> >
> > Here we go again, who says that you have to limit it to a menu?  Give
> > a menu, but allow a graphical shell during install for those that want
> > to do extra packages, or whatever.  Or, even provide a dynamically
> > extendable menu that can grab packages lists from other places, from
> > another CD, floppy, Internet, etc.  So, to not provide a menu would be
> > *limiting* as well.  But I do agree with you Holly, that providing
> > *only* a *predefined* graphical menu for package installation would be
> > limiting.
> >
> Menu of what? How will a Gentoo developer know what you want to install? If
> you are starting from Stage 3, you just need to choose what to install and
> thats it. How will a menu help you in that? As far as graphics based Gentoo
> install is concerned. I don't think that it is even anywhere near Gentoo
> Dev's priorities right now.

Really?  Then why have they already created one? Hmm.

>
> >
> > Wouldn't it be beneficial to provide automated graphical installs for
> > gentoo, but provide the option to open a graphical shell at *all*
> > stages of the installation process?  Wouldn't that be ultimate
> > flexibility?  I read about the new graphical install for gentoo, and
> > perhaps it already does this!?!?
> >
> Yes having a graphical install process would be great. Why don't you volunteer
> and try to write one for us? :)

Yeah, I would love to find the time to do that.  At this moment though
I don't have the time, as my wife would be upset with me doing extra
work when I come home from work after doing the extra work that I do
after coming home from work.  LOL.  But I certainly will when I get
the time.

>
> Regards,
> Abhay
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Sunday 08 January 2006 13:57, Trenton Adams wrote:
>
> > Menu of what? How will a Gentoo developer know what you want to install?
> > If you are starting from Stage 3, you just need to choose what to install
> > and thats it. How will a menu help you in that? As far as graphics based
> > Gentoo install is concerned. I don't think that it is even anywhere near
> > Gentoo Dev's priorities right now.
>
> Really?  Then why have they already created one? Hmm.
>
They have? Where?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Trenton Adams]

http://www.gentoo.org/proj/en/releng/installer/

On 1/8/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> On Sunday 08 January 2006 13:57, Trenton Adams wrote:
> >
> > > Menu of what? How will a Gentoo developer know what you want to install?
> > > If you are starting from Stage 3, you just need to choose what to install
> > > and thats it. How will a menu help you in that? As far as graphics based
> > > Gentoo install is concerned. I don't think that it is even anywhere near
> > > Gentoo Dev's priorities right now.
> >
> > Really?  Then why have they already created one? Hmm.
> >
> They have? Where?
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

On Sunday 08 January 2006 14:33, Trenton Adams wrote:
> http://www.gentoo.org/proj/en/releng/installer/
>
Looks great to me. Just didn't see any discussion on gentoo-dev or may be I 
missed it. So now what do you want then? You have a graphical based install 
and once you have a working system, you can install more packages. What makes 
you say that gentoo is difficult?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Trenton Adams]

ROFL. :P  I'm just saying that there's *always* room for improvement. 
And this install thing is a good start.  Automation, with flexibility
intact, is never a bad thing.

On 1/8/06, Abhay Kedia <abhay.ilugd@gmail.com> wrote:
> On Sunday 08 January 2006 14:33, Trenton Adams wrote:
> > http://www.gentoo.org/proj/en/releng/installer/
> >
> Looks great to me. Just didn't see any discussion on gentoo-dev or may be I
> missed it. So now what do you want then? You have a graphical based install
> and once you have a working system, you can install more packages. What makes
> you say that gentoo is difficult?
>
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Ernie Schroder]

On Sunday 08 January 2006 03:23, a tiny voice compelled Trenton Adams to 
write:
> Well, could be many things.  I've found fear of computers to be one
> blocker to being better at computers than one can be.  Having fear
> creates a mind block.


Why would someone with a fear of computers even consider Gentoo?
-- 
Regards, Ernie

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Trenton Adams]

On 1/8/06, Ernie Schroder <schroder@ntplx.net> wrote:
> On Sunday 08 January 2006 03:23, a tiny voice compelled Trenton Adams to
> write:
> > Well, could be many things. I've found fear of computers to be one
> > blocker to being better at computers than one can be. Having fear
> > creates a mind block.
>
>
> Why would someone with a fear of computers even consider Gentoo?

Who says they know they have a fear of computers?  You can be doing
something that you don't even know you're afraid of.  Obviously if it
was total fear, they would know about it.

> --
> Regards, Ernie
>
> --
> gentoo-user@gentoo.org mailing list
>
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] package conflict on update

[Abhay Kedia]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

On Monday 09 January 2006 02:28, Trenton Adams wrote:
>
> Who says they know they have a fear of computers?  You can be doing
> something that you don't even know you're afraid of.  Obviously if it
> was total fear, they would know about it.
>
LOL!!! Unknown fear? I have heard about "Fear of unknown" but this one is new.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] package conflict on update

[Ernie Schroder]

On Monday 09 January 2006 02:07, a tiny voice compelled Abhay Kedia to write:
> On Monday 09 January 2006 02:28, Trenton Adams wrote:
> > Who says they know they have a fear of computers?  You can be doing
> > something that you don't even know you're afraid of.  Obviously if it
> > was total fear, they would know about it.
>
> LOL!!! Unknown fear? I have heard about "Fear of unknown" but this one is
> new.


I agree Abhay. I read the above and was speachless. I'm afraid of heights and 
I damned sure know what is causing my heart to race when I'm climbimg back 
onto the ladder after working on my roof.
I seems to me that one could have an unknown fear of computers if they had 
never been exposed to one. Such a person wouldn't likely be installing 
Gentoo.
-- 
Regards, Ernie
-- 
gentoo-user@gentoo.org mailing list