[gentoo-user] anti-portage wreckage?

[gentoo-user] anti-portage wreckage?

[Mike Myers]

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

Hi!  I know I don't post here much but I read it a lot and have been using
Gentoo for several years now.  I keep seeing users mention about how they do
an update and then everything goes to crap.  I've experienced this myself
quite a bit too.  I believe the reason this happens is the drawback one of
Gentoo's nicest features; constantly being up to date.

In contrast to Gentoo, most distros have a new version released every year
or so which includes major updates like new kernels, sound drivers, updated
software, etc.  In Gentoo, the system is updated while you are using it.
This causes us users to modify whatever we're running to suit all these
changes.  Take for instance some recent packages that have had updates, like
PHP, mysql, and apache.  All three of these have had major updates at almost
the exact same time.  And then on the desktop side, we've had to deal with
the whole xorg going modular thing and other similar updates, also at the
same time.  This can be quite a headache on a live system, especially when
you have multiple systems.  Like, it's easier to mask the new versions and
just stick with the minor updates (like mysql 4.0.x, instead of going from
4.0 to 4.1 or 5), but this also leaves the users with having to manage all
of these masks for multiple systems.

Anyways, my question is that since we have profiles, like 2006.1 currently,
why can't we do something like restrict versions of apps to specific
profiles?  I'd rather be able to specify that I'm using like the 2005
profile, and then when I try to do emerge -u world, I don't have to deal
with my applications going from one major version to another major version
all by themselves and then breaking with no easy way to revert back.  This
is pretty much similar to how Red Hat works with up2date.  That way the
community wouldn't have to worry about dealing with older installs since
they could drop support for them after a while.  Also, us users can miss a
month or so of updates and not have to worry about updating 500 config files
only to realize the new version of mysql just broke like 20 other
applications and won't even start because it's using the old config.

Please tell me there's some solution to this?  I haven't seen one mentioned
anywhere yet.  Even with Gentoo's occasional problems, I like it too much to
use any other distro but I'd definitely like to see better version
management than what its got, which is none.

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

Re: [gentoo-user] anti-portage wreckage?

[david]

I have been using gentoo for over 5 years. For the first few years I
would sync and update every few days or once a week. Now I may do it
once every 6 months. I waited until the modular xorg kind of calmed down
and there were some good howto's and I updated then. I have 4 boxes here
two that are web servers and I have just gotten to lazy.

-- 
Powered by Gentoo/Linux

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] anti-portage wreckage?

[Mike Myers]

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

Yeah, the documentation is one of the many great things about Gentoo.  I
just wish the software was a little more proactive in fixing update
problems.

On 12/24/06, david <abbottdavid@bellsouth.net> wrote:
>
> I have been using gentoo for over 5 years. For the first few years I
> would sync and update every few days or once a week. Now I may do it
> once every 6 months. I waited until the modular xorg kind of calmed down
> and there were some good howto's and I updated then. I have 4 boxes here
> two that are web servers and I have just gotten to lazy.
>
> --
> Powered by Gentoo/Linux
>
> --
> gentoo-user@gentoo.org mailing list
>
>

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

Re: [gentoo-user] anti-portage wreckage?

[Andrey Gerasimenko]

On Mon, 25 Dec 2006 04:52:55 +0300, Mike Myers <fluffymikey@gmail.com>  
wrote:

>                       In Gentoo, the system is updated while you are  
> using it.
> This causes us users to modify whatever we're running to suit all these
> changes.

As far as I know, Gentoo releases a Reference Platform twice a year. So,  
you can upgrade twice a year, once a year, once in two years - all as you  
please. It will be similar to other distros, but better.

>                      I'd rather be able to specify that I'm using like  
> the 2005
> profile, and then when I try to do emerge -u world, I don't have to deal
> with my applications going from one major version to another major  
> version
> all by themselves and then breaking with no easy way to revert back.

As discussed recently in another thread of this list, there are ways to  
get back easily, backup of the portage tree being one of them. However, I  
guess your problem can be solved easier - just do not do -u world. Since  
its goal is exactly to produce what you do not want, why should you? How  
many packages do you really want to be the latest? If there are a few, it  
is easy to update them individually; if there are many, you may create a  
virtual package in the overlay and update it.

I do not here much about upgrade really breaking a Gentoo installation. If  
it did, then a fresh install also would be broken, an extremely rare case  
with stable arch. Thus, if something does not work after upgrade, then  
configuration files are out of order. Gentoo already has everything  
necessary to examine them one by one and fix as necessary.

> Please tell me there's some solution to this?  I haven't seen one  
> mentioned
> anywhere yet.  Even with Gentoo's occasional problems, I like it too  
> much to
> use any other distro but I'd definitely like to see better version
> management than what its got, which is none.

As far as I understand, no, there is no solution. If you upgrade any  
software, you have to upgrade the dependencies and configuration. All that  
can be offered, and is offered by many distros, is the upgrade option that  
should work if you installed the distro and did not change anything. Even  
that does not work pretty often, please read the reviews. For a Gentoo  
user the reason is evident - they do not have dispatch-conf. Some vendors  
have already stopped bragging that an upgrade does not break anything,  
example - Vista.

-- 
Andrei Gerasimenko
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] anti-portage wreckage?

[Mike Myers]

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

I understand what you say, but I'm not sure I got my point across very
well.  Let's say I have a server that has various things installed like
apache with the 2.0 branch, mysql with the 4.0 branch, and PHP with
the 4.xbranch.  If I do an emerge -u world on a machine with these, at
some random
point in time when the devs decide the newer branch is stable, then any one
of these will be upgraded to the next branch.  What I am asking, is why
wouldn't it be better to have it where I will only stay on the current
branch for that profile, and only move to the next branch when I change the
profile?

Like, say I have the 2005 profile, then I wouldn't have to worry about PHP
upgrading to 5.0 or randomly requiring some virtual ebuild or whatever else
is decided to be thrown our way.  I would just have to worry about updating
the 4.x branch at least until the devs decide to stop supporting it.

I think another advantage to using this method would be that it would make
it easier to transition from an application that has a monolithic ebuild to
suddenly having a modular ebuild, or a virtual ebuild.  At least this way,
we wouldn't have to worry about fundamental things changing on us during an
update until we change the profile and can expect these kinds of changes and
can deal with them at a more convenient time instead of when the devs decide
it's time to for us.

Does that make any sense?


On 12/25/06, Andrey Gerasimenko <gak@kaluga.ru> wrote:
>
> On Mon, 25 Dec 2006 04:52:55 +0300, Mike Myers <fluffymikey@gmail.com>
> wrote:
>
> >                       In Gentoo, the system is updated while you are
> > using it.
> > This causes us users to modify whatever we're running to suit all these
> > changes.
>
> As far as I know, Gentoo releases a Reference Platform twice a year. So,
> you can upgrade twice a year, once a year, once in two years - all as you
> please. It will be similar to other distros, but better.
>
> >                      I'd rather be able to specify that I'm using like
> > the 2005
> > profile, and then when I try to do emerge -u world, I don't have to deal
> > with my applications going from one major version to another major
> > version
> > all by themselves and then breaking with no easy way to revert back.
>
> As discussed recently in another thread of this list, there are ways to
> get back easily, backup of the portage tree being one of them. However, I
> guess your problem can be solved easier - just do not do -u world. Since
> its goal is exactly to produce what you do not want, why should you? How
> many packages do you really want to be the latest? If there are a few, it
> is easy to update them individually; if there are many, you may create a
> virtual package in the overlay and update it.
>
> I do not here much about upgrade really breaking a Gentoo installation. If
> it did, then a fresh install also would be broken, an extremely rare case
> with stable arch. Thus, if something does not work after upgrade, then
> configuration files are out of order. Gentoo already has everything
> necessary to examine them one by one and fix as necessary.
>
> > Please tell me there's some solution to this?  I haven't seen one
> > mentioned
> > anywhere yet.  Even with Gentoo's occasional problems, I like it too
> > much to
> > use any other distro but I'd definitely like to see better version
> > management than what its got, which is none.
>
> As far as I understand, no, there is no solution. If you upgrade any
> software, you have to upgrade the dependencies and configuration. All that
> can be offered, and is offered by many distros, is the upgrade option that
> should work if you installed the distro and did not change anything. Even
> that does not work pretty often, please read the reviews. For a Gentoo
> user the reason is evident - they do not have dispatch-conf. Some vendors
> have already stopped bragging that an upgrade does not break anything,
> example - Vista.
>
> --
> Andrei Gerasimenko
> --
> gentoo-user@gentoo.org mailing list
>
>

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

Re: [gentoo-user] anti-portage wreckage?

[Dale]

Mike Myers wrote:
> I understand what you say, but I'm not sure I got my point across very
> well.  Let's say I have a server that has various things installed
> like apache with the 2.0 branch, mysql with the 4.0 branch, and PHP
> with the 4.x branch.  If I do an emerge -u world on a machine with
> these, at some random point in time when the devs decide the newer
> branch is stable, then any one of these will be upgraded to the next
> branch.  What I am asking, is why wouldn't it be better to have it
> where I will only stay on the current branch for that profile, and
> only move to the next branch when I change the profile? 

Then you can mask them in package.mask and then it won't upgrade the
ones you don't want to upgrade.  When you get ready to upgrade, just
comment the lines in the file and upgrade. 
>
> Like, say I have the 2005 profile, then I wouldn't have to worry about
> PHP upgrading to 5.0 or randomly requiring some virtual ebuild or
> whatever else is decided to be thrown our way.  I would just have to
> worry about updating the 4.x branch at least until the devs decide to
> stop supporting it.
>
> I think another advantage to using this method would be that it would
> make it easier to transition from an application that has a monolithic
> ebuild to suddenly having a modular ebuild, or a virtual ebuild.  At
> least this way, we wouldn't have to worry about fundamental things
> changing on us during an update until we change the profile and can
> expect these kinds of changes and can deal with them at a more
> convenient time instead of when the devs decide it's time to for us.
>
> Does that make any sense?
>
>

Well, I remember xorg going modular too.  I read that some were having
problems and I just masked it for a few weeks, then upgraded after it
all got sorted out.  It worked fine for me.  I had no problems after that.

All this said, it is rare that I have trouble doing a upgrade.  Most of
my problems come in when I am using something that is masked or
keyworded.  Then you can expect to have those though.

There are ways to do what you want, it just seems to defeat the purpose
of having Gentoo in my opinion.

Dale

:-)  :-)

-- 
www.myspace.com/dalek1967

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] anti-portage wreckage?

[Andrey Gerasimenko]

On Mon, 25 Dec 2006 11:46:23 +0300, Mike Myers <fluffymikey@gmail.com>  
wrote:

> I understand what you say, but I'm not sure I got my point across very
> well.  Let's say I have a server that has various things installed like
> apache with the 2.0 branch, mysql with the 4.0 branch, and PHP with
> the 4.xbranch.  If I do an emerge -u world on a machine with these, at
> some random
> point in time when the devs decide the newer branch is stable, then any  
> one
> of these will be upgraded to the next branch.  What I am asking, is why
> wouldn't it be better to have it where I will only stay on the current
> branch for that profile, and only move to the next branch when I change  
> the
> profile?
>

I do not see any linkage between a profile, which is actually just a set  
of use variables , and application versions since there is no version data  
in a profile. (Actually there is, like minimal package versions and  
required stage 1 packages, but adding maximum versions to profile will  
make it unusable for most users) That is, profile is not a branch.

I also do not see how a branch can be created based on a profile or a  
snapshot of a portage tree. For example, if a server profile is being  
used, what PHP should be in the branch? Or, better, if I decide to install  
Qt on a server, which definitely does not have KDE, should it be 3 or 4?  
The only base for branch type versioning I see is the current set of  
installed packages.

You want to update world and, at the same time, not to update anything. I  
can understand that if your goal is not to "update world", as Portage  
thinks when you say "-u world", but to install only bug and sequrity  
fixes, as Portage does if you mask pakeges properly. As far as I remember,  
according to this list some work to treat sequrity updates differently is  
under way. As for bug fixes, I do not see how they can be separated from  
features.

I feel that what you call "branch" Portage often  calls "slot". For  
example, PHP is slotted, so that if you have PHP 4 and PHP 5 is being  
installed, your 4 does not go away.

As for ebuilds going modular, I beleive that each case is to be treated  
separately. For example, KDE is going modular now. For 3, both modular and  
monolithic ebuilds are maintained, for 4 - only modular ones. No problems  
at all, right?

I still do not see that any changes to portage are necessary. My guess is  
that your request can be formulated as a set of requests like

- this app is not slotted, it should be

- I want a script that will examine my world and mask everything so that I  
can upgrade only the last 2 version numbers

- I want another script to manage the masks set by the previous one

I hope that will be easier for developers to understand.

-- 
Andrei Gerasimenko
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] anti-portage wreckage?

[Boyd Stephen Smith Jr.]

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

On Monday 25 December 2006 04:48, "Andrey Gerasimenko" <gak@kaluga.ru> 
wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> You want to update world and, at the same time, not to update anything.
> I can understand that if your goal is not to "update world", as Portage
> thinks when you say "-u world", but to install only bug and sequrity
> fixes, as Portage does if you mask pakeges properly.

Well, if you put some work into defining exactly what package versions 
would want installed.

> As far as I 
> remember, according to this list some work to treat sequrity updates
> differently is under way. As for bug fixes, I do not see how they can be
> separated from features.

glsa-check from gentoolkit(?) should tell you exactly what packages to 
mask/upgrade to get security fixes, while bug fixes are currently handled 
exactly the same way a feature additions (generally upstream doesn't 
differentiate between these two changes either -- sometimes the y in x.y.z 
is for feature additions (with the z for bug fixes) but this isn't really 
consistent).  Gentoo-specific bug fixes are either an in-place change to 
the ebuild (no version bump) or a bump of the revision (-r1) number, which 
is independent of upstream (and should nearly universally be installed).

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

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

Re: [gentoo-user] anti-portage wreckage?

[Boyd Stephen Smith Jr.]

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

On Monday 25 December 2006 02:46, "Mike Myers" <fluffymikey@gmail.com> 
wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> I understand what you say, but I'm not sure I got my point across very
> well.  Let's say I have a server that has various things installed like
> apache with the 2.0 branch, mysql with the 4.0 branch, and PHP with
> the 4.xbranch.  If I do an emerge -u world on a machine with these, at
> some random
> point in time when the devs decide the newer branch is stable, then any
> one of these will be upgraded to the next branch.  What I am asking, is
> why wouldn't it be better to have it where I will only stay on the
> current branch for that profile, and only move to the next branch when I
> change the profile?

I would say... Move to Debian.  Gentoo dosen't have fixed branches (we have 
a live tree) even profiles don't fix much, generally minimal (not maximal) 
version numbers.

Debian, will make sure that upgrades to your (e.g.) sarge mysql package are 
either ABI compatible, or tied to other upgrades that move the ABI all at 
the same time.  This generally make Debian (and to a lesser extent Ubuntu) 
quite stable once installed.  Gentoo is.... different.

By default, Gentoo marks packages as working ("stable"), testing ("~arch"), 
or non-working ("masked by package.mask") and lets the user control the 
version(s) they want to use on their specific system (rather than 
being "attached" to a profile) with the local /etc/portage/package.mask 
(and package.keywords and package.unmask etc.).

If you decide that mysql 4 is what you want to stick with as long as gentoo 
will support it, there stick something like '>category/mysql-4*' 
or '>=category/mysql-5*' into your package.mask.  emerge will then stop 
whenever it wants newer mysql.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

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

Re: [gentoo-user] anti-portage wreckage?

[Mike Myers]

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

Thanks for the responses everybody!

Boyd, if this is just not feasible in Gentoo for whatever reason, then I
guess I might switch.  I understand the portage system enough to mask the
packages I don't want, but then there's the problem of other updates
requiring that package.

Ultimately, messing with portage is decent for a single system, but it
doesn't scale very well at all.  Managing all these different versions of
the same software on different machines running the same OS can get
ridiculously time consuming, especially if they've gone a while without
updates.  I know there are ways to better manage that, but those ways don't
work when the systems are at different locations and can't be centrally
managed.

Anyways, all I'm essentially asking for is a way to separate minor updates
from major updates.  I don't understand why this sort of update management
is 'unusable'.  If I let a system go without updates for say, a month, then
do a sync, then now I have like 200 things that need updated.  Some are
minor, like say, firefox-2.0-r1 to firefox-2.0-r2.  Then there are more
major ones like baselayout which almost completely changes how networking
and udev scripts work.  The way it is now, all these updates are lumped
together like one big update.  These kinds of updates in a short span of
time can be rough.  Especially when these new updates require config
changes, instead of just using the old config.  Like when Apache's install
was changed completely without any real warning.  It was just tossed in
there as an update, right there with gvim.  How am I supposed to know what
is and isn't going to get smashed?  I mean, sure I can wait a while and look
at the forums and see other people having problems and then wait.. but why
should we allow these problems to be there in the first place?

As for switching, I might if better update management is truly considered
'unusable'.  (???)  I just want a usable system, and I'd prefer it to be
Gentoo.

On 12/25/06, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
>
> On Monday 25 December 2006 02:46, "Mike Myers" <fluffymikey@gmail.com>
> wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> > I understand what you say, but I'm not sure I got my point across very
> > well.  Let's say I have a server that has various things installed like
> > apache with the 2.0 branch, mysql with the 4.0 branch, and PHP with
> > the 4.xbranch.  If I do an emerge -u world on a machine with these, at
> > some random
> > point in time when the devs decide the newer branch is stable, then any
> > one of these will be upgraded to the next branch.  What I am asking, is
> > why wouldn't it be better to have it where I will only stay on the
> > current branch for that profile, and only move to the next branch when I
> > change the profile?
>
> I would say... Move to Debian.  Gentoo dosen't have fixed branches (we
> have
> a live tree) even profiles don't fix much, generally minimal (not maximal)
> version numbers.
>
> Debian, will make sure that upgrades to your (e.g.) sarge mysql package
> are
> either ABI compatible, or tied to other upgrades that move the ABI all at
> the same time.  This generally make Debian (and to a lesser extent Ubuntu)
> quite stable once installed.  Gentoo is.... different.
>
> By default, Gentoo marks packages as working ("stable"), testing
> ("~arch"),
> or non-working ("masked by package.mask") and lets the user control the
> version(s) they want to use on their specific system (rather than
> being "attached" to a profile) with the local /etc/portage/package.mask
> (and package.keywords and package.unmask etc.).
>
> If you decide that mysql 4 is what you want to stick with as long as
> gentoo
> will support it, there stick something like '>category/mysql-4*'
> or '>=category/mysql-5*' into your package.mask.  emerge will then stop
> whenever it wants newer mysql.
>
> --
> "If there's one thing we've established over the years,
> it's that the vast majority of our users don't have the slightest
> clue what's best for them in terms of package stability."
> -- Gentoo Developer Ciaran McCreesh
>
>
>

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

Re: [gentoo-user] anti-portage wreckage?

[Boyd Stephen Smith Jr.]

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

On Monday 25 December 2006 14:09, "Mike Myers" <fluffymikey@gmail.com> 
wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> I understand the portage system enough to mask
> the packages I don't want, but then there's the problem of other updates
> requiring that package.

Well, either (a) the new version is required, so you'll have to upgrade to 
the other package as well or (b) a developer was sloppy with dependencies, 
and you need to file a bug to change them.

> Anyways, all I'm essentially asking for is a way to separate minor
> updates from major updates.

With some of the advanced atom operators (particularly '*' and '~'), you 
should be able to specify exactly what level of masking you want.  I 
believe this is documented in 'man ebuild' but I'm not sure; 'man portage' 
is a decent place to start your search for the atom syntax you need.

You could also make your own profile that does "cap" packges at a certain 
version and have it's parent be an established profile, although I'm not 
sure that bit of portage hackery is supported.

PS:
A: Because it reverses the order of the "conversation".
Q: Why is top-posting so annoying?
A: Top-posting.
Q: What's the most annoying thing on newsgroups and mailing lists.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

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

Re: [gentoo-user] anti-portage wreckage?

[Mike Myers]

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

On 12/25/06, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
>
> On Monday 25 December 2006 14:09, "Mike Myers" <fluffymikey@gmail.com>
> wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> > I understand the portage system enough to mask
> > the packages I don't want, but then there's the problem of other updates
> > requiring that package.
>
> Well, either (a) the new version is required, so you'll have to upgrade to
> the other package as well or (b) a developer was sloppy with dependencies,
> and you need to file a bug to change them.
>
> > Anyways, all I'm essentially asking for is a way to separate minor
> > updates from major updates.
>
> With some of the advanced atom operators (particularly '*' and '~'), you
> should be able to specify exactly what level of masking you want.  I
> believe this is documented in 'man ebuild' but I'm not sure; 'man portage'
> is a decent place to start your search for the atom syntax you need.
>
> You could also make your own profile that does "cap" packges at a certain
> version and have it's parent be an established profile, although I'm not
> sure that bit of portage hackery is supported.


I know these things could be done, but I don't really think it's worth it.
The problem is that these kinds of solutions don't scale very well.. they
don't really scale at all really.  If I have to reinstall for whatever
reason, then I have to redo all this hackery, as you put it, heh.  In any
case, this is still a bit of a reactive approach, since I have to be aware
that there may be a problem with a particular update before I know to mask
it.  I really like the idea of the tree version thing though.  I'll see if
there's anything I can do to support that.

PS:
> A: Because it reverses the order of the "conversation".
> Q: Why is top-posting so annoying?
> A: Top-posting.
> Q: What's the most annoying thing on newsgroups and mailing lists.


PS:
Noted!   Sorry :P

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

Re: [gentoo-user] anti-portage wreckage?

[Boyd Stephen Smith Jr.]

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

On Monday 25 December 2006 22:41, "Mike Myers" <fluffymikey@gmail.com> 
wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> On 12/25/06, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> > On Monday 25 December 2006 14:09, "Mike Myers" <fluffymikey@gmail.com>
> > wrote about 'Re: [gentoo-user] anti-portage wreckage?':
> > > Anyways, all I'm essentially asking for is a way to separate minor
> > > updates from major updates.
> > With some of the advanced atom operators (particularly '*' and '~'),
> > you should be able to specify exactly what level of masking you want.
> > You could also make your own profile that does "cap" packges at a
> > certain version and have it's parent be an established profile,
> > although I'm not sure that bit of portage hackery is supported.
> I know these things could be done, but I don't really think it's worth
> it. The problem is that these kinds of solutions don't scale very well..
> they don't really scale at all really.  If I have to reinstall for
> whatever reason, then I have to redo all this hackery, as you put it,
> heh.

You can easily replicate the contents of a profile or /etc/portage across 
multiple system with something like rsync; you should also have the 
entirety of /etc backed up in case you need to reinstall -- it holds all 
your services' configurations anyway.

> In any case, this is still a bit of a reactive approach, since I 
> have to be aware that there may be a problem with a particular update
> before I know to mask it.

No, you can mask packages before they exist, so you can choose to be 
reactive or active.  For example, to prevent emerge -u from updating a 
package add >category/package-version to package.mask, even if there's not 
an upgrade waiting.  Again, proper use of the package atoms should enable 
you to only enable -rX upgrades (which are ebuild changes; not upstream) 
or -rX and last version number upgrades (which should be ABI compatible if 
upstream is sane) etc. etc.

It's certainly possible to build a system of scripts around emerge to do 
all this masking for you, and the PYE (pick-your-emerge) script that is 
(used to be?) popular on the forums could be a good starting point.

One thing that would make it a *lot* easier is if /var/lib/portage/world 
supported the full atom syntax instead of just atom bases and doing 
something like 'emerge "<category/mysql-5"' would add the atom from the 
command line to the world file instead of the atom base.  [Then, most of 
the time, you wouldn't have to mask anything at all.]

> I really like the idea of the tree version 
> thing though.  I'll see if there's anything I can do to support that.

Yeah, I certainly would *mind* tree versioning.  Although... I'm not quite 
sure how it would mesh with the accepted ~ARCH keywording.  I see how they 
could work together, but they also seem to overlap uncomfortably.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

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

Re: [gentoo-user] anti-portage wreckage?

[Richard Fish]

On 12/24/06, Mike Myers <fluffymikey@gmail.com> wrote:
> Please tell me there's some solution to this?  I haven't seen one mentioned
> anywhere yet.  Even with Gentoo's occasional problems, I like it too much to
> use any other distro but I'd definitely like to see better version
> management than what its got, which is none.

The ideal solution to this would be released tree versions...so you
could use the 2006.1 tree instead of the live development tree.  Note
that profiles wouldn't help much here, as then the profile would have
to contain a list of all the possible packages that can be installed
with the relevant versions.  And it creates a lot of complications for
package removals, additions, etc.  But to have a snapshot of the tree
to which only security or other minor fixes would be applied would be
ideal for the problem you describe.

The usual argument against this is that most devs prefer working on
the live tree.  Having to maintain a released tree and backport fixes
to it would take time away from things they would rather be doing
(like working on new cool stuff).  The fear is that the released trees
could have serious security holes in them that might never get fixed.

But in fact this has been discussed many times among devs.  For the
most recent discussion, search the gentoo-dev mail list archives for
"Versioning the tree" (and ignore the flames).  I haven't reviewed the
discussion, but as I recall a couple of devs may be working on making
this a reality, possibly for the 2007.X releases.

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

Re: [gentoo-user] anti-portage wreckage?

[Mike Myers]

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

Oh, nice!  Thanks for that info!

BTW, I was only referring to the profiles since it was the closest thing to
'releases' that Gentoo has.  Whatever tool used to do it would be arbitrary
as long as it worked.  Although, wouldn't it be easier to just mask major
updates in the profile?  Like say >=application-4.1 when the profile is
using 3.0?  That way the smaller updates for 'application 3.0' could get
through.  This is assuming that a specific tree version is being used I
guess, but why would that be so hard?

On 12/25/06, Richard Fish <bigfish@asmallpond.org> wrote:
>
> On 12/24/06, Mike Myers <fluffymikey@gmail.com> wrote:
> > Please tell me there's some solution to this?  I haven't seen one
> mentioned
> > anywhere yet.  Even with Gentoo's occasional problems, I like it too
> much to
> > use any other distro but I'd definitely like to see better version
> > management than what its got, which is none.
>
> The ideal solution to this would be released tree versions...so you
> could use the 2006.1 tree instead of the live development tree.  Note
> that profiles wouldn't help much here, as then the profile would have
> to contain a list of all the possible packages that can be installed
> with the relevant versions.  And it creates a lot of complications for
> package removals, additions, etc.  But to have a snapshot of the tree
> to which only security or other minor fixes would be applied would be
> ideal for the problem you describe.
>
> The usual argument against this is that most devs prefer working on
> the live tree.  Having to maintain a released tree and backport fixes
> to it would take time away from things they would rather be doing
> (like working on new cool stuff).  The fear is that the released trees
> could have serious security holes in them that might never get fixed.
>
> But in fact this has been discussed many times among devs.  For the
> most recent discussion, search the gentoo-dev mail list archives for
> "Versioning the tree" (and ignore the flames).  I haven't reviewed the
> discussion, but as I recall a couple of devs may be working on making
> this a reality, possibly for the 2007.X releases.
>
> -Richard
> --
> gentoo-user@gentoo.org mailing list
>
>

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

[gentoo-user] Re: anti-portage wreckage?

[James]

Mike Myers <fluffymikey <at> gmail.com> writes:


> Hi!  I know I don't post here much but I read it a lot and have been using
Gentoo for several years now.  I keep seeing users mention about how they do an
update and then everything goes to crap.  I've experienced this myself quite a
bit too.  I believe the reason this happens is the drawback one of Gentoo's
nicest features; constantly being up to date. 


Hello MIke,

Folks probably will not like my suggestions, but it works
in lieu of a better schema, so aplogies to all I offend, in advance........

Gentoo servers (firewall, dns, mail, web ...) rarely suffer from these
issues, in fact, I believe one of gentoo's largest unexplored niches
should be Large Installation System Administration (via cfengine).

So, in my opinion, where Gentoo is really challenged, is the workstation
(laptop, desktop....). You know the X11 + kde/gnome software boxen. 
What I do is keep one (workstation) system
on the bleeding edge (very frequent upgrades) so as to discern
where breakage or unecessary updates are looming. Since I admin an ever
expanding hoarde of gentoo based servers and workstations, development
of some tools to compile, distribute and manage the various x86 and amd64
machines we have, is way past due. As soon as I have a scheme I'm 
happy with, we'll be deploying lots of embedded gentoo based systems.

So I update the test workstation on fridays, use it over the weekend a
nd then update the other systems. Granted, if the devs release something 
(broken) over the weekend, I get screwed with this scheme sometimes.  
I should update the test system daily (in the mornings) and then 
update the other systems on the same day after that.

Problems with that scenario is the various methods of proxying the 
downloads and syncs are problematic in and of themselvs, not very 
often, but still bad enough to make those current schemes, less 
than desirable. Futhermore, DistCC is still a 'work in progress' 
and I've experience just enough hassle that it has been disabled 
(also due in part to so many different variants of x86).

Long story short:  Gentoo is the best distro for our work, as one only
has to installed debian, suse, or redhat for a week or two, to realize
just how spoiled you get with Gentoo.  That said, I've learned to be
cautious and patient with key software upgrades on Gentoo. However this
approach burns lots of extra time. My hope is Gentoo will continue to
improve and become more of a 'production' distro, as the other Linux
distros all seem to have unacceptable flaws, for our needs.

Future:
What is really needed is a group of users, with similar needs, to define
commonality of core applications that are essential to the needs: What 
this means is a list of software, for example openoffice, kde-meta, apache,
java, perl, python, C, etc. that forms a core of what we all need (not what
we want). Then set up cfengine to push binaries, via a trusted mechanisms,
to each of the arch categories) Maybe on a weekly  basis. Each
network, business or usergroup, would use their test system for 24 hours
as a quarrantined update, before pushing to the rest of their machines.
Or maybe push sources that are know good, to the test server at each
participating location.

If fact what the one (initially) master server environment sets up 
uses, could  be duplicated at any remote location with a group of systems.
Individuals could feed (download binaries) from those locations, with
the proper security mechanisms agreed to. If  a group of locations
with multiple systems use a common update semantic, then it would be
a lot less work, as opposed to each cleaver admin, rolling their own
solution..... If something actually worked reasonable well, talented
admins could offer this service to commercial clients, thus generating
excitement about gentoo, and funding for many needy geeks.....

If you only have one or 2 gentoo sytems, something like this is not worth
the effort. For those of us looking to manage dozens to hundreds of 
gentoo based systems, the need for some management scheme, is long overdue.
JFFNMS goes a LONG way to solving the problem, but, it is not
centric to the needs of gentoo systems.  A companion project
that addresses all of those gentoo_centric issues could compliment
JFFNMS and simultaneously created that quintessential opportunity
for Gentoo to really shine, compared to it's competition.



James



-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Uwe Thiem]

On 26 December 2006 17:56, James wrote:

> So I update the test workstation on fridays, use it over the weekend a
> nd then update the other systems. Granted, if the devs release something
> (broken) over the weekend, I get screwed with this scheme sometimes.
> I should update the test system daily (in the mornings) and then
> update the other systems on the same day after that.

>From my experience, another approach is easier and safer. If your test 
workstation and your productions workstation are basically equivalent (as far 
as their world files are concerned, *not* their hardware) you can just NFS 
mount your test box's portage tree on your production box and update it from 
there. I will not download new packages but use the ones on your test box 
tested over the weekend.

>
> Problems with that scenario is the various methods of proxying the
> downloads and syncs are problematic in and of themselvs, not very
> often, but still bad enough to make those current schemes, less
> than desirable. Futhermore, DistCC is still a 'work in progress'
> and I've experience just enough hassle that it has been disabled

I disagree here. I have used distcc without any major problem for at least one 
year by now.

> (also due in part to so many different variants of x86).

This doesn't affect distcc. The slave compiles a a C or C++ according to the 
specs of the master. The master runs the source file through its preprocessor 
and sends the result with all necessary commandline options over to the 
slave. Those options contain the desired architecture/CPU of your master. The 
slave compiles the preprocessor output, runs that result through its 
assembler and transfers the resulting object file back to the master which, 
eventually, links it. So don't worry about different CPUs within the x86 
domain or different libraries.

Just have the same compiler version installed on all participating boxes.

It's a bit more difficult if a slave has a completely different architecture. 
In that case, you need to install cross compilations system for the master on 
that particular slave.

>
> Long story short:  Gentoo is the best distro for our work, as one only
> has to installed debian, suse, or redhat for a week or two, to realize
> just how spoiled you get with Gentoo.  That said, I've learned to be
> cautious and patient with key software upgrades on Gentoo. However this
> approach burns lots of extra time. My hope is Gentoo will continue to
> improve and become more of a 'production' distro, as the other Linux
> distros all seem to have unacceptable flaws, for our needs.

I full-heartedly agree here.

Uwe

-- 
A fast and easy generator of fractals for KDE:
http://www.SysEx.com.na/iwy-1.0.tar.bz2

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Mike Myers]

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

On 12/26/06, James <wireless@tampabay.rr.com> wrote:
>
> Mike Myers <fluffymikey <at> gmail.com> writes:
>
>
> > Hi!  I know I don't post here much but I read it a lot and have been
> using
> Gentoo for several years now.  I keep seeing users mention about how they
> do an
> update and then everything goes to crap.  I've experienced this myself
> quite a
> bit too.  I believe the reason this happens is the drawback one of
> Gentoo's
> nicest features; constantly being up to date.
>
>
> Hello MIke,
>
> Folks probably will not like my suggestions, but it works
> in lieu of a better schema, so aplogies to all I offend, in
> advance........
>
> Gentoo servers (firewall, dns, mail, web ...) rarely suffer from these
> issues, in fact, I believe one of gentoo's largest unexplored niches
> should be Large Installation System Administration (via cfengine).
>
> So, in my opinion, where Gentoo is really challenged, is the workstation
> (laptop, desktop....). You know the X11 + kde/gnome software boxen.
> What I do is keep one (workstation) system
> on the bleeding edge (very frequent upgrades) so as to discern
> where breakage or unecessary updates are looming. Since I admin an ever
> expanding hoarde of gentoo based servers and workstations, development
> of some tools to compile, distribute and manage the various x86 and amd64
> machines we have, is way past due. As soon as I have a scheme I'm
> happy with, we'll be deploying lots of embedded gentoo based systems.
>
> So I update the test workstation on fridays, use it over the weekend a
> nd then update the other systems. Granted, if the devs release something
> (broken) over the weekend, I get screwed with this scheme sometimes.
> I should update the test system daily (in the mornings) and then
> update the other systems on the same day after that.
>
> Problems with that scenario is the various methods of proxying the
> downloads and syncs are problematic in and of themselvs, not very
> often, but still bad enough to make those current schemes, less
> than desirable. Futhermore, DistCC is still a 'work in progress'
> and I've experience just enough hassle that it has been disabled
> (also due in part to so many different variants of x86).
>
> Long story short:  Gentoo is the best distro for our work, as one only
> has to installed debian, suse, or redhat for a week or two, to realize
> just how spoiled you get with Gentoo.  That said, I've learned to be
> cautious and patient with key software upgrades on Gentoo. However this
> approach burns lots of extra time. My hope is Gentoo will continue to
> improve and become more of a 'production' distro, as the other Linux
> distros all seem to have unacceptable flaws, for our needs.
>
> Future:
> What is really needed is a group of users, with similar needs, to define
> commonality of core applications that are essential to the needs: What
> this means is a list of software, for example openoffice, kde-meta,
> apache,
> java, perl, python, C, etc. that forms a core of what we all need (not
> what
> we want). Then set up cfengine to push binaries, via a trusted mechanisms,
> to each of the arch categories) Maybe on a weekly  basis. Each
> network, business or usergroup, would use their test system for 24 hours
> as a quarrantined update, before pushing to the rest of their machines.
> Or maybe push sources that are know good, to the test server at each
> participating location.
>
> If fact what the one (initially) master server environment sets up
> uses, could  be duplicated at any remote location with a group of systems.
> Individuals could feed (download binaries) from those locations, with
> the proper security mechanisms agreed to. If  a group of locations
> with multiple systems use a common update semantic, then it would be
> a lot less work, as opposed to each cleaver admin, rolling their own
> solution..... If something actually worked reasonable well, talented
> admins could offer this service to commercial clients, thus generating
> excitement about gentoo, and funding for many needy geeks.....
>
> If you only have one or 2 gentoo sytems, something like this is not worth
> the effort. For those of us looking to manage dozens to hundreds of
> gentoo based systems, the need for some management scheme, is long
> overdue.
> JFFNMS goes a LONG way to solving the problem, but, it is not
> centric to the needs of gentoo systems.  A companion project
> that addresses all of those gentoo_centric issues could compliment
> JFFNMS and simultaneously created that quintessential opportunity
> for Gentoo to really shine, compared to it's competition.
>
>
>
> James
>
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>

I think I like your idea better, about distributing binaries.  Do you know
if something like this is being worked on?  I'm certain that a common method
to this, like what you're saying, would allow Gentoo to become scalable to
the point of being easily usable on a large scale.

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

[gentoo-user] Re: anti-portage wreckage?

[James]

Mike Myers <fluffymikey <at> gmail.com> writes:

> 
> I think I like your idea better, about distributing binaries.  Do you know if
something like this is being worked on?  I'm certain that a common method to
this, like what you're saying, would allow Gentoo to become scalable to the
point of being easily usable on a large scale.


It's a lot of work. I'll be pusing binaries to lots of systems, but, it going
to take me months to get ready. I was hoping others with similar goals would
'band together' to come up with a solution that combines the needs for the
casual user as well as those of us that  want to manage dozens to hundres
of Gentoo systems.....

I need to refine the idea, and my goal is mostly embedded gentoo sytems, but,
they are very similar to gentoo-servers. Expanding the idea to workstation,
at least for core  software, is not that difficult.

I do not intend to get into 'competiion' with the devs, particularly on
applications that are big, complex, or prone to breakage (OO)....


It'd really be better to do this as a group, but, I've found little interest, 
most probably due to the fact that most folks are already bogged down with
their own ambitions.


James





-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Mike Myers]

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

On 12/27/06, James <wireless@tampabay.rr.com> wrote:
>
> Mike Myers <fluffymikey <at> gmail.com> writes:
>
> >
> > I think I like your idea better, about distributing binaries.  Do you
> know if
> something like this is being worked on?  I'm certain that a common method
> to
> this, like what you're saying, would allow Gentoo to become scalable to
> the
> point of being easily usable on a large scale.
>
>
> It's a lot of work. I'll be pusing binaries to lots of systems, but, it
> going
> to take me months to get ready. I was hoping others with similar goals
> would
> 'band together' to come up with a solution that combines the needs for the
> casual user as well as those of us that  want to manage dozens to hundres
> of Gentoo systems.....
>
> I need to refine the idea, and my goal is mostly embedded gentoo sytems,
> but,
> they are very similar to gentoo-servers. Expanding the idea to
> workstation,
> at least for core  software, is not that difficult.
>
> I do not intend to get into 'competiion' with the devs, particularly on
> applications that are big, complex, or prone to breakage (OO)....
>
>
> It'd really be better to do this as a group, but, I've found little
> interest,
> most probably due to the fact that most folks are already bogged down with
> their own ambitions.
>
>
> James
>
>
>
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>

I honestly believe there's a lack of interest in such thing because most
Gentoo users use it as their home computer.  The fact that Gentoo doesn't
scale very well prevents that market from growing at all, and I think that's
why there's a lack of interest in supporting such a thing.  It's kind of
like a chicken and egg thing.

I don't think setting something like this up would be competing with the
devs, unless they already had something in mind, since a project like this
would only be proxying packages and adding another package management layer
to portage.  I could be wrong though, I guess if you or whoever came up with
a solution we would see.  I don't have strong enough development skills to
help handle something like that though, but I'd love to test it out.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Aniruddha]

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

Very good ideas in this thread. Why not open a thread in the Gentoo 
forums and start a public discussion there?


In regard to your question, have you thought about the --oneshot option? 
That way you can manually upgrade the packages you see fit.

James wrote:
> Mike Myers <fluffymikey <at> gmail.com> writes:
>
>   
>> I think I like your idea better, about distributing binaries.  Do you know if
>>     
> something like this is being worked on?  I'm certain that a common method to
> this, like what you're saying, would allow Gentoo to become scalable to the
> point of being easily usable on a large scale.
>
>
> It's a lot of work. I'll be pusing binaries to lots of systems, but, it going
> to take me months to get ready. I was hoping others with similar goals would
> 'band together' to come up with a solution that combines the needs for the
> casual user as well as those of us that  want to manage dozens to hundres
> of Gentoo systems.....
>
> I need to refine the idea, and my goal is mostly embedded gentoo sytems, but,
> they are very similar to gentoo-servers. Expanding the idea to workstation,
> at least for core  software, is not that difficult.
>
> I do not intend to get into 'competiion' with the devs, particularly on
> applications that are big, complex, or prone to breakage (OO)....
>
>
> It'd really be better to do this as a group, but, I've found little interest, 
> most probably due to the fact that most folks are already bogged down with
> their own ambitions.
>
>
> James
>
>
>
>
>
>   


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

Re: [gentoo-user] Re: anti-portage wreckage?

[Mick]

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

On Sunday 31 December 2006 12:18, Aniruddha wrote:
> Very good ideas in this thread. Why not open a thread in the Gentoo
> forums and start a public discussion there?
>
>
> In regard to your question, have you thought about the --oneshot option?
> That way you can manually upgrade the packages you see fit.
>
> James wrote:
> > Mike Myers <fluffymikey <at> gmail.com> writes:
> >> I think I like your idea better, about distributing binaries.  Do you
> >> know if
> >
> > something like this is being worked on?  I'm certain that a common method
> > to this, like what you're saying, would allow Gentoo to become scalable
> > to the point of being easily usable on a large scale.
> >
> >
> > It's a lot of work. I'll be pusing binaries to lots of systems, but, it
> > going to take me months to get ready. I was hoping others with similar
> > goals would 'band together' to come up with a solution that combines the
> > needs for the casual user as well as those of us that  want to manage
> > dozens to hundres of Gentoo systems.....
> >
> > I need to refine the idea, and my goal is mostly embedded gentoo sytems,
> > but, they are very similar to gentoo-servers. Expanding the idea to
> > workstation, at least for core  software, is not that difficult.
> >
> > I do not intend to get into 'competiion' with the devs, particularly on
> > applications that are big, complex, or prone to breakage (OO)....
> >
> >
> > It'd really be better to do this as a group, but, I've found little
> > interest, most probably due to the fact that most folks are already
> > bogged down with their own ambitions.

Last few unstructured [OT] thoughts for the year . . .

There's been a couple of threads on Gentoo going out of fashion, the Linux 
desktop failing to dethrone M$Windoze, etc.  I think that this particular 
thread is interesting from another perspective, too.  Not fighting past 
battles (which distro should/could/would dominate the server market and which 
the desktop market), but fighting potential future battles.  If you're 
interested, read on.

The PC centric desktop on which M$ built their business model may be under 
threat.  If the WebOS [1], GoogleOS [2], internet based desktop [3], etc. 
take off, then what will enable Gentoo to become a predominant system of 
choice both in the server and in the thin client markets?  I don't think that 
Redmond will have much of a problem packaging a ROM embedded version of a 
thin client system and pushing it to all the Joe-public out there, who 
currently (mostly) blindly buy their products.  Inertia may of course lead to 
their demise if they continue to market the individual desktop PC solution, 
but I wouldn't count on it.

The question then is what should Gentoo do to establish itself as a major 
enabler and shaper in such a potential future?  What are the market segments 
and sub-segments and how do they come together (a home PC is these days a 
desktop apps suite; a games machine; a media center with CD/DVD/TV/music 
playing and recording capabilities, etc.)  Device and information convergence 
is increasing.

Some people will undoubtedly run their own home servers with their chosen 
desktop apps and access them via FreeNX & VNC.  For them Gentoo will be an 
option to consider.  However, I think that the vast majority will not own or 
configure their own remote access desktops.  They will readily subscribe to 
the latest M$ shop offering along with their free Hotmail account.  How could 
Gentoo increase its market share if such a potential future is to occur, or 
even better: how could Gentoo Foundation become pivotal in making it happen 
while retaining its values.

[1] http://en.wikipedia.org/wiki/Web_operating_system
[2] http://www.kottke.org/05/08/googleos-webos but there's many more articles 
& blogs out there; e.g.
[3] http://blogs.zdnet.com/web2explorer/?p=166

Happy New Year to All!
-- 
Regards,
Mick

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Uwe Thiem]

On 31 December 2006 15:40, Mick wrote:

> The PC centric desktop on which M$ built their business model may be under
> threat.  If the WebOS [1], GoogleOS [2], internet based desktop [3], etc.
> take off, then what will enable Gentoo to become a predominant system of
> choice both in the server and in the thin client markets?  I don't think
> that Redmond will have much of a problem packaging a ROM embedded version
> of a thin client system and pushing it to all the Joe-public out there, who
> currently (mostly) blindly buy their products.  Inertia may of course lead
> to their demise if they continue to market the individual desktop PC
> solution, but I wouldn't count on it.

This won't happen for various reasons.

In the business world, the main reason is security. Who will trust 
an "Internet Desktop Provider" with their internal documents?

In the world of home computing, there are actually two main reasons. The first 
is porn. The second is nearly photo-realistic games. 

Another, not that important, reason is that there are vast areas in the world 
where bandwidth is insufficient and far too expensive for it.

Uwe

-- 
A fast and easy generator of fractals for KDE:
http://www.SysEx.com.na/iwy-1.0.tar.bz2
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Mick]

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

On Sunday 31 December 2006 16:02, Uwe Thiem wrote:
> On 31 December 2006 15:40, Mick wrote:
> > The PC centric desktop on which M$ built their business model may be
> > under threat.  If the WebOS [1], GoogleOS [2], internet based desktop
> > [3], etc. take off, then what will enable Gentoo to become a predominant
> > system of choice both in the server and in the thin client markets?  I
> > don't think that Redmond will have much of a problem packaging a ROM
> > embedded version of a thin client system and pushing it to all the
> > Joe-public out there, who currently (mostly) blindly buy their products. 
> > Inertia may of course lead to their demise if they continue to market the
> > individual desktop PC solution, but I wouldn't count on it.
>
> This won't happen for various reasons.
>
> In the business world, the main reason is security. Who will trust
> an "Internet Desktop Provider" with their internal documents?

The same people who are trusting a multitude of outsourcing companies with 
their HR, Payroll, logistics, IT management and support, procurement, 
marketing, public relations, project delivery, . . . , you get the drift.  I 
wouldn't trust them any more than you do, but in the world of hollow 
corporations there are a multitude of companies out there who would trust 
nearly anybody to "take this problem away".

> In the world of home computing, there are actually two main reasons. The
> first is porn. 

Why does porn need to stored locally?!

> The second is nearly photo-realistic games. 

Of course.  That is I think one area where a thin client will not be able to 
compete with a modern desktop PC.  I don't play games and haven't seen what 
sort of latency a game played through FreeNX can achieve.  On the other hand 
future gaming may be left to games consoles?

> Another, not that important, reason is that there are vast areas in the
> world where bandwidth is insufficient and far too expensive for it.

Indeed, although most of these vast areas are sparsely populated and some of 
them are wired up as we speak - a friend who visited China 3 years ago 
mentioned that the gov't was laying yellow fibre-optic cables right across 
the country.
-- 
Regards,
Mick

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Michal 'vorner' Vaner]

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

On Sun, Dec 31, 2006 at 06:20:23PM +0000, Mick wrote:
> > The second is nearly photo-realistic games. 
> 
> Of course.  That is I think one area where a thin client will not be able to 
> compete with a modern desktop PC.  I don't play games and haven't seen what 
> sort of latency a game played through FreeNX can achieve.  On the other hand 
> future gaming may be left to games consoles?
> 
Then I hope it will be possible to have my _private_ correspondence on
a game console. I dread the times when I will have my pgp key stored
somewhere on the internet.

Another aspect is, I want to be the administrator of my computer -
because I have the power to do whatever I like ;-)

-- 

This message has optimized support for formating.
Please choose green font and black background so it looks like it should.

Michal "vorner" Vaner

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Uwe Thiem]

On 31 December 2006 20:57, Michal 'vorner' Vaner wrote:
> On Sun, Dec 31, 2006 at 06:20:23PM +0000, Mick wrote:
> > > The second is nearly photo-realistic games.
> >
> > Of course.  That is I think one area where a thin client will not be able
> > to compete with a modern desktop PC.  I don't play games and haven't seen
> > what sort of latency a game played through FreeNX can achieve.  On the
> > other hand future gaming may be left to games consoles?
>
> Then I hope it will be possible to have my _private_ correspondence on
> a game console. I dread the times when I will have my pgp key stored
> somewhere on the internet.
>
> Another aspect is, I want to be the administrator of my computer -
> because I have the power to do whatever I like ;-)

We aren't talking about *you* or *me*. We are talking about future trends. 
These involve a helluva more people than yourself. ;-)

Uwe

-- 
A fast and easy generator of fractals for KDE:
http://www.SysEx.com.na/iwy-1.0.tar.bz2
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Uwe Thiem]

On 31 December 2006 20:20, Mick wrote:
> On Sunday 31 December 2006 16:02, Uwe Thiem wrote:

> > This won't happen for various reasons.
> >
> > In the business world, the main reason is security. Who will trust
> > an "Internet Desktop Provider" with their internal documents?
>
> The same people who are trusting a multitude of outsourcing companies with
> their HR, Payroll, logistics, IT management and support, procurement,
> marketing, public relations, project delivery, . . . , you get the drift. 
> I wouldn't trust them any more than you do, but in the world of hollow
> corporations there are a multitude of companies out there who would trust
> nearly anybody to "take this problem away".

On the other hand, I know enough companies that don't do that - and I do IT 
consultancy jobs for them. I don't doubt that a large number of companies is 
hollow and stupid. The questions is what the ratio is between those that 
store their latest blueprints inhouse and those that don't. I do not know. Do 
you? I mean hard numbers, not guesses. The other question is what the top 100 
will do. Will Ford keep their internal strategic papers on the servers of an 
Internet Desktop Provider (IDP)? Will Dow Chemical? DaimlerChrysler? Exxon? 
You get the drift. ;-)

>
> > In the world of home computing, there are actually two main reasons. The
> > first is porn.
>
> Why does porn need to stored locally?!

Many daddies John Doe might not understand the implications of storing 
potentially embarrassing (and often illegal) data on someone else's servers. 
Many, if not the majority, will at least have their suspicions and probably 
chicken out of  IDPs.

How significant is this? Well, I had the task to analyse the logs of a 
transparent proxy of a local ISP for some time. It was quite amazing. Just 
short of 50% of HTTP traffic was porn. About 80% of their subscribers were 
regular porn site visitors. So yes, it is significant.
 
>
> > The second is nearly photo-realistic games.
>
> Of course.  That is I think one area where a thin client will not be able
> to compete with a modern desktop PC.  I don't play games and haven't seen
> what sort of latency a game played through FreeNX can achieve.  On the
> other hand future gaming may be left to games consoles?

NX is a truly amazing technology. I tried a full KDE desktop over a bloody 
modem line, and it reacted as if local. Still, the games I am talking about  
put a far higher stress on the local system *and* the bandwidth. Still, if 
thin clients would get far better video subsystems *and* much more ram they 
might do the trick.

>
> > Another, not that important, reason is that there are vast areas in the
> > world where bandwidth is insufficient and far too expensive for it.
>
> Indeed, although most of these vast areas are sparsely populated and some
> of them are wired up as we speak - a friend who visited China 3 years ago
> mentioned that the gov't was laying yellow fibre-optic cables right across
> the country.

While China is a huge part of the world population-wise. it isn't all of it 
outside the US. Besides, fibre-optics aren't all of it. We have a backbone of 
them as well. Still, the average bandwidth a client can expect is somewhere 
between 3 and 4 KB/s.

Anyway, since you use gmail.com, you are at least outsourcing your email. ;-) 
Not too bad, I admit - as long as you aren't sending incriminating or simply 
confidential stuff through them.

Uwe

-- 
A fast and easy generator of fractals for KDE:
http://www.SysEx.com.na/iwy-1.0.tar.bz2
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Mike Myers]

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

On 12/31/06, Mick <michaelkintzios@gmail.com> wrote:
>
> On Sunday 31 December 2006 12:18, Aniruddha wrote:
> > Very good ideas in this thread. Why not open a thread in the Gentoo
> > forums and start a public discussion there?
> >
> >
> > In regard to your question, have you thought about the --oneshot option?
>
> > That way you can manually upgrade the packages you see fit.
> >
> > James wrote:
> > > Mike Myers <fluffymikey <at> gmail.com> writes:
> > >> I think I like your idea better, about distributing binaries.  Do you
>
> > >> know if
> > >
> > > something like this is being worked on?  I'm certain that a common
> method
> > > to this, like what you're saying, would allow Gentoo to become
> scalable
> > > to the point of being easily usable on a large scale.
> > >
> > >
> > > It's a lot of work. I'll be pusing binaries to lots of systems, but,
> it
> > > going to take me months to get ready. I was hoping others with similar
>
> > > goals would 'band together' to come up with a solution that combines
> the
> > > needs for the casual user as well as those of us that  want to manage
> > > dozens to hundres of Gentoo systems.....
> > >
> > > I need to refine the idea, and my goal is mostly embedded gentoo
> sytems,
> > > but, they are very similar to gentoo-servers. Expanding the idea to
> > > workstation, at least for core  software, is not that difficult.
> > >
> > > I do not intend to get into 'competiion' with the devs, particularly
> on
> > > applications that are big, complex, or prone to breakage (OO)....
> > >
> > >
> > > It'd really be better to do this as a group, but, I've found little
> > > interest, most probably due to the fact that most folks are already
> > > bogged down with their own ambitions.
>
> Last few unstructured [OT] thoughts for the year . . .
>
> There's been a couple of threads on Gentoo going out of fashion, the Linux
>
> desktop failing to dethrone M$Windoze, etc.  I think that this particular
> thread is interesting from another perspective, too.  Not fighting past
> battles (which distro should/could/would dominate the server market and
> which
> the desktop market), but fighting potential future battles.  If you're
> interested, read on.
>
> The PC centric desktop on which M$ built their business model may be under
> threat.  If the WebOS [1], GoogleOS [2], internet based desktop [3], etc.
> take off, then what will enable Gentoo to become a predominant system of
> choice both in the server and in the thin client markets?  I don't think
> that
> Redmond will have much of a problem packaging a ROM embedded version of a
> thin client system and pushing it to all the Joe-public out there, who
> currently (mostly) blindly buy their products.  Inertia may of course lead
> to
> their demise if they continue to market the individual desktop PC
> solution,
> but I wouldn't count on it.


I'm sure others will disagree, but I really think if Gentoo is going to
become a cornerstone in the desktop's replacement (like for thin clients)
then there should probably be an option for a binary 'version' of portage.
Gentoo is great in so many ways, but having to compile everything is
sometimes just very unnecessary.  I mean it's great if you want to teak your
desktop, but it's just time consuming on a server or a slower embedded
machine, and worst of all there's no benefit for compiling things in those
areas.  The other problem thing that will hold it back, I believe anyway, is
the constant updating instead of release cycles.  This can make
administration very harsh on a system that you can only access remotely.

I am fully aware that there are "solutions" to both of these problems, but
none of those solutions are standardized at all and are also not supported
by Gentoo's devs.  Like, there's no 'Gentoo' way of doing such things.
Perhaps if there were, then Gentoo would be a more realistic approach to
networked computing.


The question then is what should Gentoo do to establish itself as a major
> enabler and shaper in such a potential future?  What are the market
> segments
> and sub-segments and how do they come together (a home PC is these days a
> desktop apps suite; a games machine; a media center with CD/DVD/TV/music
> playing and recording capabilities, etc.)  Device and information
> convergence
> is increasing.
>
> Some people will undoubtedly run their own home servers with their chosen
> desktop apps and access them via FreeNX & VNC.  For them Gentoo will be an
>
> option to consider.  However, I think that the vast majority will not own
> or
> configure their own remote access desktops.  They will readily subscribe
> to
> the latest M$ shop offering along with their free Hotmail account.  How
> could
> Gentoo increase its market share if such a potential future is to occur,
> or
> even better: how could Gentoo Foundation become pivotal in making it
> happen
> while retaining its values.


As far as typical home users go, they don't really buy into things unless
it's easy to use.  Mainly because they are wanting a tool to accomplish a
task.  If Gentoo can provide that tool, then getting it into the living room
wouldn't be a big deal.  As it is now, unfortunately, Gentoo is not designed
to be 'easy to use' in the sense of the average user's experience.  Once it
is, then it will be easier to market.  I like the ability to tinker with
Gentoo, but I just wish it wasn't a requirement to use it.


[1] http://en.wikipedia.org/wiki/Web_operating_system
> [2] http://www.kottke.org/05/08/googleos-webos but there's many more
> articles
> & blogs out there; e.g.
> [3] http://blogs.zdnet.com/web2explorer/?p=166
>
> Happy New Year to All!
> --
> Regards,
> Mick
>
>
>

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Mike Myers]

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

I just wanted to add something to the original post.

I've recently began experimenting with Debian and noticed their updating
system is exactly like what I was asking about.  Basically, there's package
updates, and then there's distro updates.  Why is it unreasonable for Gentoo
to have something like this?  I think it would help Gentoo a lot in the
server market, where scalability is important.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Mark Kirkwood]

Mike Myers wrote:
> I just wanted to add something to the original post.
> 
> I've recently began experimenting with Debian and noticed their updating 
> system is exactly like what I was asking about.  Basically, there's 
> package updates, and then there's distro updates.  Why is it 
> unreasonable for Gentoo to have something like this?  I think it would 
> help Gentoo a lot in the server market, where scalability is important.

While this is true, one of the differentiating points of Gentoo is 
precisely the build-from-source idea (there are plenty of binary update 
distros out there).

One other thing - to actually do what you are suggesting requires a fair 
number of extra volunteers to maintain these package updates. Now I'm 
not saying its not possible, or even a bad idea mind - just wore work... 
and maybe that effort might be better spent on keeping the current 
momentum and quality of Gentoo as it is (or improving it)...

Cheers

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Mark Knecht]

> Mike Myers wrote:
> > I just wanted to add something to the original post.
> >
> > I've recently began experimenting with Debian and noticed their updating
> > system is exactly like what I was asking about.  Basically, there's
> > package updates, and then there's distro updates.  Why is it
> > unreasonable for Gentoo to have something like this?  I think it would
> > help Gentoo a lot in the server market, where scalability is important.
>

While I might personally like what you are suggesting I think that the
idea fails under the load of trying to get the community to agree on
what use flags/compiler flags, etc. would be the standard that all
these packages are built with. Do you make the binary packages small
or do you make them full featured? Do you support AMD CPU flags?
Intel? Both or neither somehow?

Personally I think there are so many options in Gentoo that coming up
with agreement on what to do will be pretty difficult.

That said if a set of binary packages were out there I'd probably
investigate using it for certain machines, but most likely never my
personal desktop machine.

Cheers,
Mark
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Mike Myers]

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

On 12/31/06, Mark Knecht <markknecht@gmail.com> wrote:
>
> > Mike Myers wrote:
> > > I just wanted to add something to the original post.
> > >
> > > I've recently began experimenting with Debian and noticed their
> updating
> > > system is exactly like what I was asking about.  Basically, there's
> > > package updates, and then there's distro updates.  Why is it
> > > unreasonable for Gentoo to have something like this?  I think it would
> > > help Gentoo a lot in the server market, where scalability is
> important.
> >
>
> While I might personally like what you are suggesting I think that the
> idea fails under the load of trying to get the community to agree on
> what use flags/compiler flags, etc. would be the standard that all
> these packages are built with. Do you make the binary packages small
> or do you make them full featured? Do you support AMD CPU flags?
> Intel? Both or neither somehow?
>
> Personally I think there are so many options in Gentoo that coming up
> with agreement on what to do will be pretty difficult.
>
> That said if a set of binary packages were out there I'd probably
> investigate using it for certain machines, but most likely never my
> personal desktop machine.
>
> Cheers,
> Mark
> --
> gentoo-user@gentoo.org mailing list
>
>

I wasn't referring to the use of binary packages at all.  I was only
referring to how updates are managed (or lack thereof) in Gentoo.  What USE
flags and whatnot are set wouldn't need to be affected at all, I would
think.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Neil Walker]

Mike Myers wrote:
> I just wanted to add something to the original post.
>
> I've recently began experimenting with Debian and noticed their 
> updating system is exactly like what I was asking about.  Basically, 
> there's package updates, and then there's distro updates.  Why is it 
> unreasonable for Gentoo to have something like this?  I think it would 
> help Gentoo a lot in the server market, where scalability is important.
If Debian does what you want then why not go with it?  What would be the 
point in making Gentoo like Debian? Gentoo offers a different approach 
which many of us like.  It's all about choice - if you like Debian, 
choose it - but don't expect Gentoo to turn into a Debian clone. It's 
not going to happen.


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Mike Myers]

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

On 12/31/06, Mark Kirkwood <markir@paradise.net.nz> wrote:Mike Myers wrote:
> > I just wanted to add something to the original post.
> >
> > I've recently began experimenting with Debian and noticed their updating
> > system is exactly like what I was asking about.  Basically, there's
> > package updates, and then there's distro updates.  Why is it
> > unreasonable for Gentoo to have something like this?  I think it would
> > help Gentoo a lot in the server market, where scalability is important.
>
> While this is true, one of the differentiating points of Gentoo is
> precisely the build-from-source idea (there are plenty of binary update
> distros out there).


I'm not trying to suggest that Gentoo should go to a binary distro or
anything like that.  Besides, it's easy enough to just use a binary package
server if that's what one needs.  I'm just wondering why there isn't some
kind of update management system to like, differentiate minor updates like
firefox 1.5.0.5 to firefox 1.5.0.7 and major ones like, y'know, gcc 3.4.4 to
4+?  The way it is now, they're all lumped together like one big update.
The lack of such a system might make it easier for the devs.. but this is a
pain in the ass for the users when they run into a problem like this
unexpectedly.  It's even worse when that user is managing several Gentoo
machines.  This kind of thing does not scale at all.


One other thing - to actually do what you are suggesting requires a fair
> number of extra volunteers to maintain these package updates. Now I'm
> not saying its not possible, or even a bad idea mind - just wore work...
> and maybe that effort might be better spent on keeping the current
> momentum and quality of Gentoo as it is (or improving it)...
>
> Cheers
>
> Mark
> --
> gentoo-user@gentoo.org mailing list
>

I don't see why it would take that much work.  If the tree was versioned,
then the profile could be more significant with what was updated.  Like, in
the ebuild it could have a single additional entry for a minimum profile.
Then, that user won't have to deal with that update until they update their
profile.  I'm sure there's other ways of doing that, but from what I've seen
of portage and it's scripts, it is quite flexible for changes such as this.
If anything, this could just be a gradual addition to new scripts instead of
editing each and every ebuild.  Whatever the solution is if there is going
to be one at all should not be a complicated one, or it would defeat the
purpose altogether.


On 12/31/06, Neil Walker <neil@ep.mine.nu> wrote:
>
> Mike Myers wrote:
> > I just wanted to add something to the original post.
> >
> > I've recently began experimenting with Debian and noticed their
> > updating system is exactly like what I was asking about.  Basically,
> > there's package updates, and then there's distro updates.  Why is it
> > unreasonable for Gentoo to have something like this?  I think it would
> > help Gentoo a lot in the server market, where scalability is important.
> If Debian does what you want then why not go with it?  What would be the
> point in making Gentoo like Debian? Gentoo offers a different approach
> which many of us like.  It's all about choice - if you like Debian,
> choose it - but don't expect Gentoo to turn into a Debian clone. It's
> not going to happen.
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>

The update system is the -only- nice thing about it over Gentoo.  Debian is
nowhere near Gentoo when it comes to everything else (especially docs).  I
don't think suggesting a single feature that another distro has and putting
into Gentoo is trying to make it a clone.  I'm just asking for a relief from
having to constantly worry if updating something out of the 300 packages
that need updated is going to break something, and not having to make sure
etc-update isn't going to destroy my custom configs afterwards.  If it
wasn't for that, Gentoo would be perfect.  I'm sure there's got to be others
that would agree.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Mark Kirkwood]

Mike Myers wrote:

> (snippage)
> I'm not trying to suggest that Gentoo should go to a binary distro or 
> anything like that.   I'm just wondering why there 
> isn't some kind of update management system to like, differentiate minor 
> updates like firefox 1.5.0.5 <http://1.5.0.5> to firefox 1.5.0.7 
> <http://1.5.0.7> and major ones like, y'know, gcc 3.4.4 to 4+? 

Ok - sorry, was misled by the mentioning of packages!


> 
> The update system is the -only- nice thing about it over Gentoo.  Debian 
> is nowhere near Gentoo when it comes to everything else (especially 
> docs).  I don't think suggesting a single feature that another distro 
> has and putting into Gentoo is trying to make it a clone.  I'm just 
> asking for a relief from having to constantly worry if updating 
> something out of the 300 packages that need updated is going to break 
> something, and not having to make sure etc-update isn't going to destroy 
> my custom configs afterwards.  If it wasn't for that, Gentoo would be 
> perfect.  I'm sure there's got to be others that would agree.


Yeah, it would be good to know an update is not going to give a broken 
system - but to implement some sort of (extra) tagged release testing 
would be a significant amount of effort for the community. In addition 
it could be argued that there is potentially little real gain in doing 
this, as it is *never* possible to ensure no breakage (e.g. Microsoft 
updates are a case in point...).

At the end of the day, regardless of whatever release 
engineering/quality process Gentoo (or any software product) has, you 
really have to follow the steps:

1/ Update (1 or more) machines in your test environment.
2/ Run your test suite.
3/ Update the rest of your machines if 2/ pases.

Personally I don't see why this does not scale.


Cheers

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Neil Bothwick]

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

On Mon, 01 Jan 2007 23:36:02 +1300, Mark Kirkwood wrote:

> Yeah, it would be good to know an update is not going to give a broken 
> system - but to implement some sort of (extra) tagged release testing 
> would be a significant amount of effort for the community.

Only if you rely on the current developer community to do this. There's
nothing to stop a user or group of users from taking a snapshot of the
portage tree and applying only security updates (after testing of
course) then using that as their own rsync source for a "static"
Gentoo-based distro. If the target hardware is all compatible, you could
also build packages so that all updates on production machines would be
done with the --usepkg option, saving time and CPU cycles.


-- 
Neil Bothwick

Sure, we just route the main sensor through Data's cat.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Aniruddha]

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

I totally agree to neil's assessment. Mike certainly has point that 
Debian is more mature in some aspects (is has been around since '93). 
That being said it is lacking so much in other departments that for me 
it is no serious alternative to Gentoo (difficulty installing source 
packages not in the apt repositories, inferior security support in 
comparison to Gentoo to name a few).

I really believe we should give  Gentoo some time to evolve  (Gentoo was 
first released in 2002)  In time gentoo will become more mature and 
better fit to our needs. In order to achieve this however we all need to 
put an effort into making Gentoo the best distro available. So please 
stop talking and get moving. Open a thread, mobilize people, contact 
aforementioned Gentoo businesses. _Contribute_ in any way possible to 
realize the features you envision.
>
>
>
> On 12/31/06, *Neil Walker* <neil@ep.mine.nu <mailto:neil@ep.mine.nu>> 
> wrote:
>
>     Mike Myers wrote:
>     > I just wanted to add something to the original post.
>     >
>     > I've recently began experimenting with Debian and noticed their
>     > updating system is exactly like what I was asking
>     about.  Basically,
>     > there's package updates, and then there's distro updates.  Why is it
>     > unreasonable for Gentoo to have something like this?  I think it
>     would
>     > help Gentoo a lot in the server market, where scalability is
>     important.
>     If Debian does what you want then why not go with it?  What would
>     be the
>     point in making Gentoo like Debian? Gentoo offers a different approach
>     which many of us like.  It's all about choice - if you like Debian,
>     choose it - but don't expect Gentoo to turn into a Debian clone. It's
>     not going to happen.
>
>
>     --
>     gentoo-user@gentoo.org <mailto:gentoo-user@gentoo.org> mailing list
>
>
>
> The update system is the -only- nice thing about it over Gentoo.  
> Debian is nowhere near Gentoo when it comes to everything else 
> (especially docs).  I don't think suggesting a single feature that 
> another distro has and putting into Gentoo is trying to make it a 
> clone.  I'm just asking for a relief from having to constantly worry 
> if updating something out of the 300 packages that need updated is 
> going to break something, and not having to make sure etc-update isn't 
> going to destroy my custom configs afterwards.  If it wasn't for that, 
> Gentoo would be perfect.  I'm sure there's got to be others that would 
> agree.


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

Re: [gentoo-user] Re: anti-portage wreckage?

[Daniel Barkalow]

On Sun, 31 Dec 2006, Mike Myers wrote:

> On 12/31/06, Mark Kirkwood <markir@paradise.net.nz> wrote:Mike Myers wrote:
> > > I just wanted to add something to the original post.
> > >
> > > I've recently began experimenting with Debian and noticed their updating
> > > system is exactly like what I was asking about.  Basically, there's
> > > package updates, and then there's distro updates.  Why is it
> > > unreasonable for Gentoo to have something like this?  I think it would
> > > help Gentoo a lot in the server market, where scalability is important.
> >
> > While this is true, one of the differentiating points of Gentoo is
> > precisely the build-from-source idea (there are plenty of binary update
> > distros out there).
> 
> 
> I'm not trying to suggest that Gentoo should go to a binary distro or
> anything like that.  Besides, it's easy enough to just use a binary package
> server if that's what one needs.  I'm just wondering why there isn't some
> kind of update management system to like, differentiate minor updates like
> firefox 1.5.0.5 to firefox 1.5.0.7 and major ones like, y'know, gcc 3.4.4 to
> 4+?  The way it is now, they're all lumped together like one big update.
> The lack of such a system might make it easier for the devs.. but this is a
> pain in the ass for the users when they run into a problem like this
> unexpectedly.  It's even worse when that user is managing several Gentoo
> machines.  This kind of thing does not scale at all.

The problem is that the chance of something breaking gets higher the more 
you do at once, and the chance of something you need to be able to recover 
also breaking goes up sharply. I've been watching people use Debian for 
quite a while now, and I've rarely if ever seen a system upgrade without 
major problems. People have problems like: the new release has a version 
of Apache that has a different config file arrangement, and it's hard to 
make a new config file that handles the web app the system is supposed to 
be running; the old Apache worked fine, but the new release doesn't use 
it, and the old binary requires a ton of libraries that the new release 
doesn't have, either. And there's no easy way to downgrade to the old 
release until you have time to mess with config files.

With Gentoo, you find that the new apache doesn't work with your config 
files, so you mask it until you have time to deal with it.

> I'm just asking for a relief from having to constantly worry if updating 
> something out of the 300 packages that need updated is going to break 
> something, and not having to make sure etc-update isn't going to destroy 
> my custom configs afterwards.  If it wasn't for that, Gentoo would be 
> perfect.  I'm sure there's got to be others that would agree.

Well, there are two goals here: make it so you can do all the safe updates 
without any of the ones which will require manual fixing, and make it so 
your custom configs are protected.

I think it would be useful to have an ebuild thing for "upgrading to this 
package from version {expression} requires the following steps", such that 
the message will be displayed only if you're doing that, and such that the 
upgrade will be masked if you're being conservative in upgrading.

I also think that emerge should keep track of the config files installed 
by packages, so that etc-update knows if you've got local modifications, 
and give you a big warning when you might lose a change you made.

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Neil Bothwick]

On Tue, 2 Jan 2007 01:50:27 -0500 (EST), Daniel Barkalow wrote:

> I think it would be useful to have an ebuild thing for "upgrading to
> this package from version {expression} requires the following steps",
> such that the message will be displayed only if you're doing that, and
> such that the upgrade will be masked if you're being conservative in
> upgrading.

It already does, with has_version. Look at the pkg_setup() part of the
postfix ebuild for an example of this in use.


-- 
Neil Bothwick

I will always cherish the initial misconceptions I had about you.


-- 
Neil Bothwick

Top Oxymorons Number 22: Childproof
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Daniel Barkalow]

On Tue, 2 Jan 2007, Neil Bothwick wrote:

> On Tue, 2 Jan 2007 01:50:27 -0500 (EST), Daniel Barkalow wrote:
> 
> > I think it would be useful to have an ebuild thing for "upgrading to
> > this package from version {expression} requires the following steps",
> > such that the message will be displayed only if you're doing that, and
> > such that the upgrade will be masked if you're being conservative in
> > upgrading.
> 
> It already does, with has_version. Look at the pkg_setup() part of the
> postfix ebuild for an example of this in use.

Perhaps it just needs to be more popular, or maybe it needs to understand 
slots better (in order to be popular). I know that all of the kernels I 
install tell me that support for devfs was removed long before the oldest 
kernel available in portage as of when I installed the machine.

It also doesn't look like it's something where it would be able to choose 
to upgrade postfix 2.2.10 to 2.2.10-r1 instead of to 2.3.5 because 2.3.5 
would require help and 2.2.10-r1 is automatic.

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Neil Bothwick]

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

On Wed, 3 Jan 2007 00:45:00 -0500 (EST), Daniel Barkalow wrote:

> Perhaps it just needs to be more popular, or maybe it needs to
> understand slots better (in order to be popular). I know that all of
> the kernels I install tell me that support for devfs was removed long
> before the oldest kernel available in portage as of when I installed
> the machine.

File a bug, the ebuild shouldn't be reporting this if it is unnecessary or
confusing.

> It also doesn't look like it's something where it would be able to
> choose to upgrade postfix 2.2.10 to 2.2.10-r1 instead of to 2.3.5
> because 2.3.5 would require help and 2.2.10-r1 is automatic.

This is Gentoo, you are supposed to make those sort of decisions for
yourself. Automatic updates go against the "the admin is in control"
ethos.


-- 
Neil Bothwick

Bang on the LEFT side of your computer to restart Windows

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Daniel Barkalow]

On Wed, 3 Jan 2007, Neil Bothwick wrote:

> On Wed, 3 Jan 2007 00:45:00 -0500 (EST), Daniel Barkalow wrote:
> 
> > Perhaps it just needs to be more popular, or maybe it needs to
> > understand slots better (in order to be popular). I know that all of
> > the kernels I install tell me that support for devfs was removed long
> > before the oldest kernel available in portage as of when I installed
> > the machine.
> 
> File a bug, the ebuild shouldn't be reporting this if it is unnecessary or
> confusing.

I think I'll wait a little while for the new bug tracker, but that's 
something worth reporting, I guess.

> > It also doesn't look like it's something where it would be able to
> > choose to upgrade postfix 2.2.10 to 2.2.10-r1 instead of to 2.3.5
> > because 2.3.5 would require help and 2.2.10-r1 is automatic.
> 
> This is Gentoo, you are supposed to make those sort of decisions for
> yourself. Automatic updates go against the "the admin is in control"
> ethos.

Gentoo makes a lot of the particular version decisions based on your 
policy decisions. E.g., it'll currently use 2.2.10 and not either 
2.2.10-r1 or 2.3.5 if you don't have ~x86. It would make sense to have 
>=2.3 masked ("by user-intervention requirement") if you have <2.3 
installed, like 2.2.10-r1 is masked "by keyword". Masking >=2.3 by hand 
works, but it would be nice to exactly mask the ebuilds that would call 
die in pkg_setup given your status.

(For that matter, it would be nice to have emerge able to tell you about 
masked versions that you might find interesting; I was interested in mysql 
5 going stable, despite having >=4.1 masked, and didn't find out until a 
while later)

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Bo Ørsted Andresen]

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

On Thursday 04 January 2007 09:44, Neil Bothwick wrote:
> > > File a bug, the ebuild shouldn't be reporting this if it is unnecessary
> > > or confusing.
> >
> > I think I'll wait a little while for the new bug tracker, but that's
> > something worth reporting, I guess.
>
> You can file it on the new bug tracker at  http://bugstest.gentoo.org

Well, he can but no devs will see it. It doesn't send mails and it'll get a 
new import from the old tracker when it replaces old wiping anything anyone 
filed on the new tracker at bugstest...

-- 
Bo Andresen

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Alan McKinnon]

On Tuesday 02 January 2007 08:50, Daniel Barkalow wrote:
> I also think that emerge should keep track of the config files
> installed by packages, so that etc-update knows if you've got local
> modifications, and give you a big warning when you might lose a
> change you made.

Huh? Portage already does this. Standard config dirs are 
CONFIG_PROTECTed which is where etc-update comes in. It will merge 
trivial changes (whitespace, etc) and let *you* chose what to do for 
everything else. You get to keep the original file, use the update, or 
use a customized merge of the two.

There is no need to give you a big warning if you might lose a change - 
the very act of running etc-update at all IS that warning. It's 
understood that if the new file shows up, then you DO have local 
modifications

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Daniel Barkalow]

On Tue, 2 Jan 2007, Alan McKinnon wrote:

> On Tuesday 02 January 2007 08:50, Daniel Barkalow wrote:
> > I also think that emerge should keep track of the config files
> > installed by packages, so that etc-update knows if you've got local
> > modifications, and give you a big warning when you might lose a
> > change you made.
> 
> Huh? Portage already does this. Standard config dirs are 
> CONFIG_PROTECTed which is where etc-update comes in. It will merge 
> trivial changes (whitespace, etc) and let *you* chose what to do for 
> everything else. You get to keep the original file, use the update, or 
> use a customized merge of the two.

The issue is that etc-update doesn't have the version of the config file 
as installed by the version of the package that's being replaced, so it 
can't tell the difference between non-trivial changes to the config file 
as shipped by gentoo between the old version and the new version and 
non-trivial local modifications that I've made myself to a config file 
which has not been changed between package versions. I've definitely had 
etc-update ask for confirmation on files I'm sure I didn't change 
(including, in some cases, executables that get installed in protected 
directories).

> There is no need to give you a big warning if you might lose a change - 
> the very act of running etc-update at all IS that warning. It's 
> understood that if the new file shows up, then you DO have local 
> modifications

It's understood that there is a difference between what I'm using now and 
what new package comes with. But there's no information on whether that 
difference came from local modifications.

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Alan McKinnon]

On Wednesday 03 January 2007 07:21, Daniel Barkalow wrote:
> On Tue, 2 Jan 2007, Alan McKinnon wrote:
> > On Tuesday 02 January 2007 08:50, Daniel Barkalow wrote:
> > > I also think that emerge should keep track of the config files
> > > installed by packages, so that etc-update knows if you've got
> > > local modifications, and give you a big warning when you might
> > > lose a change you made.
> >
> > Huh? Portage already does this. Standard config dirs are
> > CONFIG_PROTECTed which is where etc-update comes in. It will merge
> > trivial changes (whitespace, etc) and let *you* chose what to do
> > for everything else. You get to keep the original file, use the
> > update, or use a customized merge of the two.
>
> The issue is that etc-update doesn't have the version of the config
> file as installed by the version of the package that's being
> replaced, so it can't tell the difference between non-trivial changes
> to the config file as shipped by gentoo between the old version and
> the new version and non-trivial local modifications that I've made
> myself to a config file which has not been changed between package
> versions. I've definitely had etc-update ask for confirmation on
> files I'm sure I didn't change (including, in some cases, executables
> that get installed in protected directories).

Neither the computer nor etc-update can think. So why are you asking it 
to think? Because that's what you are asking it to do - make an 
intelligent decision about a config file based on it's contents and how 
it differs from a new version.

The only possible thing etc-update could ever do is look for trivial 
changes and ignore them. How would you detect the difference between 
non-trivial changes to shipped versions and non-trivial changes made 
locally? You can't say that if the config file exists and hasn't 
changed since installation then overwrite it with the new shipped 
version - that might change the behaviour of an *existing* system 
(without notification) if the user likes the old way and does not like 
the new way.

This will cause b.g.o. to be flooded with bugs about how emerge 
obliterated working config files - are you going to be the one to 
answer all those bug reports? 

> > There is no need to give you a big warning if you might lose a
> > change - the very act of running etc-update at all IS that warning.
> > It's understood that if the new file shows up, then you DO have
> > local modifications
>
> It's understood that there is a difference between what I'm using now
> and what new package comes with. But there's no information on
> whether that difference came from local modifications.

And neither should there be. Etc-update knows the files are *different* 
and stops right there. Evaluating what that difference means is a 
human's job because it's not a monkey-see, monkey-do process.

Again: the computer cannot think. Don't expect it to.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Daniel Barkalow]

On Wed, 3 Jan 2007, Alan McKinnon wrote:

> The only possible thing etc-update could ever do is look for trivial 
> changes and ignore them. How would you detect the difference between 
> non-trivial changes to shipped versions and non-trivial changes made 
> locally?

Keep a copy of the config files for installed packages somewhere in /var, 
and provide etc-update with "this is the version we shipped that's going 
away" on package removal. Currently, it only keeps the hash of the config 
file that goes with a package, so it can only tell whether there was a 
change in the shipped version, not what that change was. Portage actually 
has enough information to detect that the user has modified a 
CONFIG_PROTECTed file (moveme and destmd5 != cfgfiledict.get[myrealdest]), 
but doesn't test this or communicate it to etc-update.

> You can't say that if the config file exists and hasn't 
> changed since installation then overwrite it with the new shipped 
> version - that might change the behaviour of an *existing* system 
> (without notification) if the user likes the old way and does not like 
> the new way.

I didn't say it shouldn't require interaction to get the new shipped 
version; I said it should require extra confirmation to discard changes 
made locally. It should also be able to offer 3-way merge instead of 
2-way, and automatically retain local changes that don't conflict with 
shipped changes.

> > It's understood that there is a difference between what I'm using now
> > and what new package comes with. But there's no information on
> > whether that difference came from local modifications.
> 
> And neither should there be. Etc-update knows the files are *different* 
> and stops right there. Evaluating what that difference means is a 
> human's job because it's not a monkey-see, monkey-do process.

What the difference means is up to the humans, but there's no reason, 
aside from having carelessly lost information previously, that it doesn't 
know where the change came from; that part isn't up to human 
interpretation, and it's valuable information for humans trying to 
evaluate what the difference means.

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Alan McKinnon]

On Wednesday 03 January 2007 20:24, Daniel Barkalow wrote:
> On Wed, 3 Jan 2007, Alan McKinnon wrote:
> > The only possible thing etc-update could ever do is look for
> > trivial changes and ignore them. How would you detect the
> > difference between non-trivial changes to shipped versions and
> > non-trivial changes made locally?
>
> Keep a copy of the config files for installed packages somewhere in
> /var, and provide etc-update with "this is the version we shipped
> that's going away" on package removal. Currently, it only keeps the
> hash of the config file that goes with a package, so it can only tell
> whether there was a change in the shipped version, not what that
> change was. Portage actually has enough information to detect that
> the user has modified a CONFIG_PROTECTed file (moveme and destmd5 !=
> cfgfiledict.get[myrealdest]), but doesn't test this or communicate it
> to etc-update.

That doesn't work in real life. The system can detect if files have 
changed, where they changed, when they changed and even who changed 
them. It does not know, and never will know, *why* the change happened 
and what the intention of the user was in making the change. Even if a 
config file has not been changed and a new different version exists, 
the system has no way to determine whether the existing unchanged 
version exactly meets my needs or not and whether an automatic update 
will cause me (the admin) to flip my lid and flame the dev as a result 
(or not). The machine does not know, the code does not know and the dev 
does not know. Only *I* know and *I* am the only person that can make 
this decision.

Unix users tend to use it because (amongst other things) the system does 
not try and second guess us and pull a "we know better than you" stunt. 
If I want that behaviour, I'll migrate to Windows thank you very much.

I know etc-update is a pain in the ass, especially after emerge -uND 
world and I have to make decisions on 100 CONFIG_PROTECTed files. But 
even so it's miles better than the alternative.

> > You can't say that if the config file exists and hasn't
> > changed since installation then overwrite it with the new shipped
> > version - that might change the behaviour of an *existing* system
> > (without notification) if the user likes the old way and does not
> > like the new way.
>
> I didn't say it shouldn't require interaction to get the new shipped
> version; I said it should require extra confirmation to discard
> changes made locally. It should also be able to offer 3-way merge
> instead of 2-way, and automatically retain local changes that don't
> conflict with shipped changes.

Please define exactly what a "change that doesn't conflict with shipped 
changes" means so that I can design a correct algorithm and implement 
it in C or Python. Include deprecated options, syntax changes, subtle 
changes in meaning, redefined syntax commands and new conflicting 
options in config files with the same name across version changes. make 
it bullet proof so that any regular dev can list these things easily in 
confidence of their correctness, where the user will know the impact 
without resorting to looking it up every time, and where the correct 
thing (defined by whatever $ARB_USER happens to believe they want) is 
done in the vast overwhelming majority of cases.

I'm not jerking your chain here - that is the real spec of a system like 
you propose. I'm not being pedantic and nit-picking - these are the 
kind of detail things that make or break software. Windows Update fails 
in the real world as Microsoft implements vast sweeping monolithic 
changes leaving the user with no meaningful way to control the process 
other than "do not apply SPx". Lets not even put one toe onto that 
road...

The various update tools do the only realistic thing possible - the user 
said to not touch these files, so it doesn't. Period.

> > > It's understood that there is a difference between what I'm using
> > > now and what new package comes with. But there's no information
> > > on whether that difference came from local modifications.
> >
> > And neither should there be. Etc-update knows the files are
> > *different* and stops right there. Evaluating what that difference
> > means is a human's job because it's not a monkey-see, monkey-do
> > process.
>
> What the difference means is up to the humans, but there's no reason,
> aside from having carelessly lost information previously, that it
> doesn't know where the change came from; that part isn't up to human
> interpretation, and it's valuable information for humans trying to
> evaluate what the difference means.

Now you are changing the goal posts. Previously you said the tools 
should be doing automated changes. Now you say the tools should 
highlight (as a diff perhaps) what the changes are. Which is it?

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Daniel Barkalow]

On Thu, 4 Jan 2007, Alan McKinnon wrote:

> On Wednesday 03 January 2007 20:24, Daniel Barkalow wrote:
>
> > I didn't say it shouldn't require interaction to get the new shipped
> > version; I said it should require extra confirmation to discard
> > changes made locally. It should also be able to offer 3-way merge
> > instead of 2-way, and automatically retain local changes that don't
> > conflict with shipped changes.
> 
> Please define exactly what a "change that doesn't conflict with shipped 
> changes" means so that I can design a correct algorithm and implement 
> it in C or Python.

Take the diff between the original version and the local version, and call 
this "local". Take the diff between the original version and the new 
shipped version, and call this "remote". Represent each of these diffs as 
a series of hunks. Step through the original file, and, by splitting on 
each hunk boundary in either of the diffs, produce a series of hunks, 
where each hunk has at least one version; if there is more than one 
version, ask the user for help in merging that hunk. The versions are:

 - the original, if neither side has any changes.
 - the local, if only the local has a change. (*)
 - the original and the remote, if only the remote has a change. (+)
 - the local and the remote, if both diffs have changes.

When multiple versions are available, make it clear what those versions 
are, ask for additional confirmation if the choices are "local" and 
"remote" and the user picks "remote" rather than using "local" or writing 
a new version by hand.

Also allow arbitrary edits to the file, in case the user has to fix up 
syntax.

(*) Optionally, "the original and the local", if the user is particularly 
paranoid and wants to check over the purely local modifications.

(+) This is the difference between this algorithm and RCS's "merge": 
changes made remotely can be rejected.

> Include deprecated options, syntax changes, subtle changes in meaning, 
> redefined syntax commands and new conflicting options in config files 
> with the same name across version changes. make it bullet proof so that 
> any regular dev can list these things easily in confidence of their 
> correctness, where the user will know the impact without resorting to 
> looking it up every time, and where the correct thing (defined by 
> whatever $ARB_USER happens to believe they want) is done in the vast 
> overwhelming majority of cases.

I don't think the paranoid user case is actually that significant. Either 
the shipped version has to compensate for the change in semantics, in 
which case there will be a remote change, which demands user interaction; 
or the shipped version doesn't change, in which case the current 
etc-update doesn't help you, because the shipped versions before and after 
are identical and emerge doesn't tell etc-update to do anything.

Note that my algorithm never treats a file entirely automatically unless 
the current etc-update also would treat it entirely automatically. Mine 
just acts on a per-hunk level instead of a per-file level, and also 
provides additional information on what's going on.

> I'm not jerking your chain here - that is the real spec of a system like 
> you propose. I'm not being pedantic and nit-picking - these are the 
> kind of detail things that make or break software. Windows Update fails 
> in the real world as Microsoft implements vast sweeping monolithic 
> changes leaving the user with no meaningful way to control the process 
> other than "do not apply SPx". Lets not even put one toe onto that 
> road...

There's sort of a continuum of bad designs, from "no information and no 
control" to "no information and lots of control". It doesn't help the user 
much to have tons of control if there's no information to base a decision 
on. Think about how bad etc-update would be if it didn't tell you the 
filename you were working on. Microsoft does both of these bad things 
("stuff just happens, and the computer might not work" and "you have to 
make this critical decision: 'yes' or 'no'").

Gentoo is far better, but I think etc-update would be a lot better with 
more information given to the user; e.g., the choice for "replace the old 
shipped configuration with a new shipped configuration" should be a 
different key from "replace the locally-modified configuration with a new 
shipped configuration", rather than both being "replace the current 
configuration with the new shipped configuration".

I don't actually mind the 100 files in etc-update all that much. The issue 
is that the first 99 are files I've never touched where I've never 
even learned the config file syntax, or the occasional executable in a 
weird place, or init scripts I haven't modified, or examples that aren't 
actually used, and the 100th one is my coworker's lovingly hand-crafted 
CUPS configuration, and I'm half asleep by the time I get to it. It should 
be able to tell that I've got local modifications, and warn me that I'm in 
danger of losing work on the config file. It's just kind of cruel to make 
me decide what to do with that file without mentioning this information.

> The various update tools do the only realistic thing possible - the user 
> said to not touch these files, so it doesn't. Period.

Well, then the user turns to etc-update for help in getting the files 
right. At that point, the system should do something, and it ought to be 
as helpful as possible. (Actually, I think that it would be even better to 
have the etc-update/dispatch-conf step done before the ebuild qmerge step, 
so that the user's chosen config file is merged at the same time as 
everything else, but that's another thing entirely.)

> Now you are changing the goal posts. Previously you said the tools 
> should be doing automated changes. Now you say the tools should 
> highlight (as a diff perhaps) what the changes are. Which is it?

I never said the tools should be doing automated changes. I thought that 
you thought that the *were* doing automated changes (because you said that 
they would only present you with files with local modification), and I was 
arguing that this claim was wrong; this has nothing to do with what they 
*should* be doing. I should have been more clear initially that I think
automatically replacing locally-unmodified config files is a bad idea, in 
addition to not being the status quo.

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Boyd Stephen Smith Jr.]

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

On Saturday 06 January 2007 00:43, Daniel Barkalow <barkalow@iabervon.org> 
wrote about 'Re: [gentoo-user] Re: anti-portage wreckage?':
> (Actually, I think that it would be even better
> to have the etc-update/dispatch-conf step done before the ebuild qmerge
> step, so that the user's chosen config file is merged at the same time
> as everything else, but that's another thing entirely.)

Well, emerge is supposed to be able to be run without interaction; some 
packages (doom3, for example) do require action, but it's generally 
frowned upon.  (And some ebuilds, like webapp-config's have be be massaged 
because configuration files are modified after all merges are complete.)

More on topic, I like your idea, but not in a position right now to make 
the necessary hacks to portage.

-- 
"If there's one thing we've established over the years,
it's that the vast majority of our users don't have the slightest
clue what's best for them in terms of package stability."
-- Gentoo Developer Ciaran McCreesh

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Neil Bothwick]

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

On Wed, 3 Jan 2007 00:21:02 -0500 (EST), Daniel Barkalow wrote:

> The issue is that etc-update doesn't have the version of the config
> file as installed by the version of the package that's being replaced,
> so it can't tell the difference between non-trivial changes to the
> config file as shipped by gentoo between the old version and the new
> version and non-trivial local modifications that I've made myself to a
> config file which has not been changed between package versions. I've
> definitely had etc-update ask for confirmation on files I'm sure I
> didn't change 

I haven't use etc-update for a while, but dispatch-conf can do this.

# Automerge files that the user hasn't modified
# (yes or no)
replace-unmodified=no

Whether this is a good idea is a completely separate issue. If a service
had a config file change between versions and the file was updated to the
new format while the old daemon was still running, the results could be
"interesting".


-- 
Neil Bothwick

Found my .sig, it was in behind the cushion on the settee.

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

RE: [gentoo-user] Re: anti-portage wreckage?

[Nelson, David (ED, PAR&D)]

Hi folks,

	Has the idea of distributing custom package.mask files occured?
This way you can "mask off" certain versions of software and hence limit
updates to minor changes. You can then use these on systems you want to
keep as stable as possible, use a test machine to test changes to the
package.mask and then roll it out. Might make management of many
workstations/servers easier.

Alternatively incorporating a custom package.mask into a custom boot CD
could provide the basis of a Gentoo-derived custom distro?

I use the word "custom" too much.

David

Note: These views are my own, advice is provided with no guarantee of
success. I do not represent anyone else in any emails I send to this
list.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Hans-Werner Hilse]

Hi,

On Wed, 3 Jan 2007 11:03:34 -0000 "Nelson, David (ED, PAR&D)"
<David.Nelson2@astrazeneca.com> wrote:

> 	Has the idea of distributing custom package.mask files
> occured? This way you can "mask off" certain versions of software and
> hence limit updates to minor changes. You can then use these on
> systems you want to keep as stable as possible, use a test machine to
> test changes to the package.mask and then roll it out. Might make
> management of many workstations/servers easier.

Naah, it wouldn't work by itself. You would still have to have a
"trusted state" portage tree in order to make sure what's _not_ masked.

It's far easier to replicate a known-state portage tree.

> Alternatively incorporating a custom package.mask into a custom boot
> CD could provide the basis of a Gentoo-derived custom distro?
> 
> I use the word "custom" too much.

No, that's the outcome of this thread, I think. It's all about
customization. Customization that makes a streamlined distro impossible
to use for majority of Gentoo's users.


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

Re: [gentoo-user] Re: anti-portage wreckage?

[Alan McKinnon]

On Wednesday 03 January 2007 13:03, Nelson, David (ED, PAR&D) wrote:
> Hi folks,
>
> 	Has the idea of distributing custom package.mask files occured?
> This way you can "mask off" certain versions of software and hence
> limit updates to minor changes. You can then use these on systems you
> want to keep as stable as possible, use a test machine to test
> changes to the package.mask and then roll it out. Might make
> management of many workstations/servers easier.
>
> Alternatively incorporating a custom package.mask into a custom boot
> CD could provide the basis of a Gentoo-derived custom distro?


portage already does this, in the profile. It's what defines 
the 'system' package set.

For an example, look in the files 
in /usr/portage/profiles/default-linux/x86/2006.1/ - you can define USE 
flags, required packages, versions of those packages, and basically 
everything you mention above

alan

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Neil Bothwick]

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

On Wed, 3 Jan 2007 11:03:34 -0000, Nelson, David \(ED, PAR&D\) wrote:

> 	Has the idea of distributing custom package.mask files occured?
> This way you can "mask off" certain versions of software and hence limit
> updates to minor changes. You can then use these on systems you want to
> keep as stable as possible, use a test machine to test changes to the
> package.mask and then roll it out. Might make management of many
> workstations/servers easier.

What happens when there are no unmasked version of a package available?
You'd then have to start copying ebuilds to overlays etc. A "release
tree" would be much easier, especially as it appears the devs may do the
work for you from 2007.0.


-- 
Neil Bothwick

If at first you don't succeed, bugger.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Daniel Barkalow]

On Wed, 3 Jan 2007, Neil Bothwick wrote:

> On Wed, 3 Jan 2007 00:21:02 -0500 (EST), Daniel Barkalow wrote:
> 
> > The issue is that etc-update doesn't have the version of the config
> > file as installed by the version of the package that's being replaced,
> > so it can't tell the difference between non-trivial changes to the
> > config file as shipped by gentoo between the old version and the new
> > version and non-trivial local modifications that I've made myself to a
> > config file which has not been changed between package versions. I've
> > definitely had etc-update ask for confirmation on files I'm sure I
> > didn't change 
> 
> I haven't use etc-update for a while, but dispatch-conf can do this.
> 
> # Automerge files that the user hasn't modified
> # (yes or no)
> replace-unmodified=no
> 
> Whether this is a good idea is a completely separate issue. If a service
> had a config file change between versions and the file was updated to the
> new format while the old daemon was still running, the results could be
> "interesting".

I actually wanted the opposite feature: have an extra confirmation 
required for replacing a locally-modified file. And it shouldn't require 
all of the extra bookkeeping of dispatch-conf to get this, although 
dispatch-conf is clearly a lot closer.

	-Daniel
*This .sig left intentionally blank*
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Alan McKinnon]

On Monday 01 January 2007 04:34, Mike Myers wrote:
> The update system is the -only- nice thing about it over Gentoo.
>  Debian is nowhere near Gentoo when it comes to everything else
> (especially docs).  I don't think suggesting a single feature that
> another distro has and putting into Gentoo is trying to make it a
> clone.  I'm just asking for a relief from having to constantly worry
> if updating something out of the 300 packages that need updated is
> going to break something, and not having to make sure etc-update
> isn't going to destroy my custom configs afterwards.  If it wasn't
> for that, Gentoo would be perfect.  I'm sure there's got to be others
> that would agree.

At this point it might be helpful to revisit what gentoo really *is* in 
engineering terms

Gentoo is not an off-the-shelf, commodity, we-do-everything-for-you and 
you don't have to think (much) distro, it's in a completely different 
class. The devs have given up the ability to configure things a certain 
way and handed that control over to you. You get increased 
customizability but have to pay the price of increased knowledge and 
responsibility, including that you get to keep both pieces when you 
break it.

Red Hat and Ubuntu can do all these tests for you, the gentoo devs can't 
(except in some very broad cases like package-1.0 is config-file 
incompatible with package-2.x), so we gentoo-users have to do these 
tests ourselves.

Remember the old joke: "We can make it cheaply, quickly, correctly. Pick 
any two." You have a case like this, maybe it's time to just get over 
it :-)

alan


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Mike Myers]

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

On 1/2/07, Alan McKinnon <alan@linuxholdings.co.za> wrote:
>
> On Monday 01 January 2007 04:34, Mike Myers wrote:
> > The update system is the -only- nice thing about it over Gentoo.
> > Debian is nowhere near Gentoo when it comes to everything else
> > (especially docs). I don't think suggesting a single feature that
> > another distro has and putting into Gentoo is trying to make it a
> > clone. I'm just asking for a relief from having to constantly worry
> > if updating something out of the 300 packages that need updated is
> > going to break something, and not having to make sure etc-update
> > isn't going to destroy my custom configs afterwards. If it wasn't
> > for that, Gentoo would be perfect. I'm sure there's got to be others
> > that would agree.
>
> At this point it might be helpful to revisit what gentoo really *is* in
> engineering terms
>
> Gentoo is not an off-the-shelf, commodity, we-do-everything-for-you and
> you don't have to think (much) distro, it's in a completely different
> class. The devs have given up the ability to configure things a certain
> way and handed that control over to you. You get increased
> customizability but have to pay the price of increased knowledge and
> responsibility, including that you get to keep both pieces when you
> break it.



What I was suggesting wouldn't take away from that at all.

Red Hat and Ubuntu can do all these tests for you, the gentoo devs can't
> (except in some very broad cases like package-1.0 is config-file
> incompatible with package-2.x), so we gentoo-users have to do these
> tests ourselves.


I don't completely disagree.  But, I would just like to at least be aware
that I am testing something and that I can half expect it to break.  Like,
then otherwise what's the point of using ~x86 if x86 is still testing?  If
I'm using x86, I don't see why it's so wrong, (or against the Gentoo
philosophy as it seems to be) to expect a reasonably stable system
(obviously not perfectly stable).

Remember the old joke: "We can make it cheaply, quickly, correctly. Pick
> any two." You have a case like this, maybe it's time to just get over
> it :-)


I'll have to remember that one :P

alan
>
>
> --
> gentoo-user@gentoo.org mailing list
>
>

Gentoo has release cycles anyway, like 2006.0, 2006.1, etc.  So why is it so
much to ask to use those profiles to actually be used to deal with updates?
It's apparently being discussed by the devs anyway.  Although, when I ask
about such a feature I feel as though I'm somehow threatening the Gentoo
community or philosophy with some kind of ticking time bomb or something.
It's not like adding one feature towards stability is going to cause people
to confuse Gentoo with Red Hat or something just totally insane and left
field.  I'd rather see something like this though than something like random
ebuilds being redesigned somehow and breaking randomly because something was
slotted out of the blue, or went modular and now has to build 600 packages.
I guess my main concern is simply the randomness of the portage tree.  If
'tree versions' were actually implemented, like what is/was being discussed,
then that issue would dissolve.  This would also give users more options,
which from what I understand is the Gentoo philosophy.  They could have a
'testing' tree where it's up to date as possible like the current method, or
they could use a released tree.  Where the packages in that tree suffer no
major changes (like going modular or virtual) or go from one branch (or
"slot") to another with an emerge -u* world.

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

Re: [gentoo-user] Re: anti-portage wreckage?

[William Kenworthy]

On Sun, 2006-12-31 at 19:01 -0600, Mike Myers wrote:
> I just wanted to add something to the original post.
> 
> I've recently began experimenting with Debian and noticed their
> updating system is exactly like what I was asking about.  Basically,
> there's package updates, and then there's distro updates.  Why is it
> unreasonable for Gentoo to have something like this?  I think it would
> help Gentoo a lot in the server market, where scalability is
> important.

Gentoo has "system" and "world" - in concept almost the same thing

Apologies if this has been pointed out already.

However, on most of my machines "system" is empty (went that way soon
after each install - no idea why) so all I am left with is "world".  Is
there any way to regen "system"? (like regenworld does for world?)
Perhaps a "system" file can be manually created using only the packages
from world that the user wants?

BillK

>  
-- 
William Kenworthy <billk@iinet.net.au>
Home!
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Richard Fish]

On 12/31/06, William Kenworthy <billk@iinet.net.au> wrote:
> However, on most of my machines "system" is empty (went that way soon
> after each install - no idea why) so all I am left with is "world".

What do mean?  The "system" package set is defined by
/usr/portage/profiles/base/packages, and extended by the "packages"
file of whatever profile you are running.

Does "emerge -evp system" really report no packages to merge?

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

Re: [gentoo-user] Re: anti-portage wreckage?

[William Kenworthy]

On Sun, 2006-12-31 at 21:35 -0700, Richard Fish wrote:
> On 12/31/06, William Kenworthy <billk@iinet.net.au> wrote:
> > However, on most of my machines "system" is empty (went that way soon
> > after each install - no idea why) so all I am left with is "world".
> 
> What do mean?  The "system" package set is defined by
> /usr/portage/profiles/base/packages, and extended by the "packages"
> file of whatever profile you are running.
> 
> Does "emerge -evp system" really report no packages to merge?
> 
> -Richard

rattus ~ # emerge system -ep

These are the packages that would be merged, in order:

Calculating system dependencies ... done!
rattus ~ #

3 systems like this, one installed only a few months ago works.

:)
BillK

-- 
William Kenworthy <billk@iinet.net.au>
Home!
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Bo Ørsted Andresen]

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

On Monday 01 January 2007 06:58, William Kenworthy wrote:
> rattus ~ # emerge system -ep
>
> These are the packages that would be merged, in order:
>
> Calculating system dependencies ... done!
> rattus ~ #
>
> 3 systems like this, one installed only a few months ago works.

And `emerge --info` ?

-- 
Bo Andresen

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

Re: [gentoo-user] Re: anti-portage wreckage?

[William Kenworthy]

On Tue, 2007-01-02 at 12:19 +0100, Bo Ørsted Andresen wrote:
> On Monday 01 January 2007 06:58, William Kenworthy wrote:
> > rattus ~ # emerge system -ep
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating system dependencies ... done!
> > rattus ~ #
> >
> > 3 systems like this, one installed only a few months ago works.
> 
> And `emerge --info` ?
> 

rattus ~ # emerge --info
Portage 2.1.1-r2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r4,
2.6.19-gentoo-r2 i686)
=================================================================
System uname: 2.6.19-gentoo-r2 i686 AMD Athlon(tm) XP 2500+
Gentoo Base System version 1.12.6
Last Sync: Fri, 29 Dec 2006 05:20:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[enabled]
ccache version 2.3 [enabled]
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.7, 2.0.31
dev-lang/python:     2.3.5-r3, 2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.3
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.15.92.0.2-r10, 2.16.1-r3
sys-devel/gcc-config: 1.3.14
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.8.1-r1, 2.6.17-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-w -mcpu=athlon-xp -march=athlon-xp -mtune=athlon-xp -O2 -pipe
-fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fforce-addr"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-w -mcpu=athlon-xp -march=athlon-xp -mtune=athlon-xp -O2 -pipe
-fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fforce-addr"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distcc distlocks metadata-transfer sandbox
sfperms strict"
GENTOO_MIRRORS="ftp.iinet.net.au/pub/Gentoo"
LANG="en_AU.UTF-8"
LC_ALL="en_AU.UTF-8"
LINGUAS="en"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --delete-after --stats
--timeout=180 --exclude='/distfiles' --exclude='/local'
--exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowex 3dnowext 7zip X X509 Xaw3d a52 aac aalib
activefilter adns aim alsa alsa_cards_ali5451 alsa_cards_als4000
alsa_cards_atiixp alsa_cards_atiixp-modem alsa_cards_bt87x
alsa_cards_ca0106 alsa_cards_cmipci alsa_cards_emu10k1x
alsa_cards_ens1370 alsa_cards_ens1371 alsa_cards_es1938
alsa_cards_es1968 alsa_cards_fm801 alsa_cards_hda-intel
alsa_cards_intel8x0 alsa_cards_intel8x0m alsa_cards_maestro3
alsa_cards_trident alsa_cards_usb-audio alsa_cards_via82xx
alsa_cards_via82xx-modem alsa_cards_ymfpci alsa_pcm_plugins_adpcm
alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy
alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop
alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file
alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug
alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear
alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi
alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate
alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm
alsa_pcm_plugins_softvol apache2 apm arts asf audiofile avahi
bash-completion berkdb bidi bigger-fonts binfilter bitmap-fonts blas
bluetooth bonobo browserplugin buffysize bzip2 bzlib c++ cairo cap cdda
cddb cdparanoia cdr cgi cli corba cpudetection cracklib crypt cscope css
cups curl daap dbus devmap dga dhcp divx divx4linux djvu dlloader dnd
doc dri dts dv dvb dvd dvdr dvdread dvi dxr3 edl eds elibc_glibc emboss
encode erandom escreen esd ethereal evo exif expat extensions faad fam
fame fbcon fbsplash ffmpeg fftw firefox flac flash font-server
foomaticdb fortran fpx freetds freetype gb gd gdbm ggi gif gimp
gimpprint ginac glade glgd glibc-omitfp glut gmedia gmp gnome
gnome-print gnomedb gnuplot gnutls gphoto2 gpm graphviz gs gsl gstreamer
gtk gtk2 gtkhtml guile gzip hal hdf hdf5 howl-compat hpn httpd iconv icq
idn imagemagick imap imlib imlib2 inkjar innodb input_devices_evdev
input_devices_keyboard input_devices_mouse isdnlog jabber java
javascript jbig jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility
kdexdeltas kernel_linux kig-scripting kqemu largeterminal lcms ldap
libcaca libclamav libg++ libgda libsamplerate libwww linguas_en live
logitech-mouse logrotate lua lzo lzw-tiff mad maildir matroska mbrola
mcal mdb mdnsresponder-compat mhash mikmod ming mjpeg mmx mmx2 mmxext
mng modplug motif mozctl mozilla moznocompose moznoirc moznomail mozp3p
mozplaintext mozsvg mozxmlterm mp3 mp4 mpeg mpeg4 mplayer msn multislot
multiuser mupad-noscilab musepack music musicbrainz mysql mythtv native
nautilus ncurses network nls nntp nocardbus nocd nptl nptlonly nsplugin
ntlm nvidia nviz oav objc odbc offensive ogg openal openexr opengl
operanom2 oscar oss pam parse-clocks passfile pcap pcntl pcre pda pdf
pdfkit pear-db perl pg-hier php physfs pic plotutils plugin png pnp
posix postgres povray ppds pppd profile python qemu-fast qt3 qt4
quicktime quotes rar readline real realmedia reflection rtc rtsp samba
scanner screen sdl seamonkey sensord server session sftplogging shout
silc slang smime sms sndfile snmp soap sox speedo speex speexvorbis
spell spl sse sse2 ssl stencil-buffer stream svg svga swat t1lib tcl
tcltk tcpd tetex tga theora threads tidy tiff tk tokenizer toolbar
transcode transparent-proxy truetype truetype-fonts type1 type1-fonts
udev unicode usb userland_GNU uudeview v4l v4l2 vcd vcdimager vda vdr
video_cards_nvidia video_cards_vesa video_cards_vga videos vidix vim
vim-with-x vlm vnc vorbis vorbis-psy webdav wifilm_sensors win32codecs
wmf wmp wsconvert wxgtk1 wxwindows x264 xanim xbase xchatdccserver
xchattext xcomposite xface xine xinetd xml xml2 xmlreader xmlrpc
xmlwriter xorg xosd xpm xprint xrandr xscreensaver xsl xv xvid xvmc yv12
zip zlib zvbi"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS


-- 
William Kenworthy <billk@iinet.net.au>
Home!
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: anti-portage wreckage?

[Bo Ørsted Andresen]

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

On Tuesday 02 January 2007 14:26, William Kenworthy wrote:
> > > rattus ~ # emerge system -ep
> > >
> > > These are the packages that would be merged, in order:
> > >
> > > Calculating system dependencies ... done!
> > > rattus ~ #
> > >
> > > 3 systems like this, one installed only a few months ago works.
> >
> > And `emerge --info` ?

There's probably a better way to do this but this should output what 
constitutes your system packages. It should be 61 lines on your profile.

# cd /etc && cd $(readlink /etc/make.profile) && \
while [[ true ]]; do
    if [[ -f packages ]]; then
        egrep -v "^$|^#" packages;
    fi
    if [[ -f parent ]]; then
        cd $(cat parent);
    else
        break;
    fi;
done

-- 
Bo Andresen

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Neil Bothwick]

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

On Sun, 31 Dec 2006 19:01:25 -0600, Mike Myers wrote:

> I've recently began experimenting with Debian and noticed their updating
> system is exactly like what I was asking about.  Basically, there's
> package updates, and then there's distro updates.  Why is it
> unreasonable for Gentoo to have something like this?  I think it would
> help Gentoo a lot in the server market, where scalability is important.

Look at the gentoo-dev thread that Richard pointed out (versioning the
tree). The release tree idea discussed there seems to be similar to what
you are suggesting.


-- 
Neil Bothwick

Do PAL taglines take up two scanlines?

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

Re: [gentoo-user] Re: anti-portage wreckage?

[Andrey Gerasimenko]

On Mon, 01 Jan 2007 02:29:12 +0300, Mike Myers <fluffymikey@gmail.com>  
wrote:

> I'm sure others will disagree, but I really think if Gentoo is going to
> become a cornerstone in the desktop's replacement (like for thin clients)
> then there should probably be an option for a binary 'version' of  
> portage.
> Gentoo is great in so many ways, but having to compile everything is
> sometimes just very unnecessary.  I mean it's great if you want to teak  
> your
> desktop, but it's just time consuming on a server or a slower embedded
> machine, and worst of all there's no benefit for compiling things in  
> those
> areas.  The other problem thing that will hold it back, I believe  
> anyway, is
> the constant updating instead of release cycles.  This can make
> administration very harsh on a system that you can only access remotely.
>

AFAIK Gentoo is a meta-distribution. That is, its goal is to make it  
easier to create other distributions. When somebody installs Gentoo,  
compiles packages, and uses the resulting binaries for whatever purpose,  
there is a possibility to wrongfully conclude that the Gentoo distribution  
is being used by an end user. In fact, it has been used by a distribution  
developer to create a customized distribution which in its own turn has  
been used by an end user, while the fact that the distro developer and the  
end user are the same person is mere coincidence.

Is it still true?

If it is still true, then why should Gentoo, as represented by its  
developers, care if there are any servers too busy to compile anything and  
too deep in production to allow for testing upgrades?

Indeed, how can Gentoo distribute binary packages when it does not know  
your CFLAGS and USE? One answer could be to run a server that takes CFLAGS  
and USE returning the resulting binary package. The server can be run by  
the Gentoo Foundation if it finds that the idea has business sense, but  
this issue is transcendental to Gentoo as a Distribution.

How can Gentoo test if an update brakes something when it does not know  
the state of the system before the update? Possibly it could, if the  
portage tree had versions and users were severely limited in what  
configuration changes they can do. But how is it different from creating  
another distribution that is just based on Gentoo like Ubuntu is based on  
Debian?

>> How
>> could
>> Gentoo increase its market share if such a potential future is to occur,
>> or
>> even better: how could Gentoo Foundation become pivotal in making it
>> happen
>> while retaining its values.
>

Does Gentoo Foundation need greater market share? My impression is that  
developers need more good developers, not home users. I do not know what  
the Trustees want to achieve, but I guess that influence can be measured  
not only in the number of users, but also by the probability that Gentoo  
patches are accepted upstream, the number of application developers that  
release ebuilds, and the number of distributions that are based on or  
using Gentoo (really do not know how to find out if Gentoo is used by  
other distribution developers).

>
> As far as typical home users go, they don't really buy into things unless
> it's easy to use.  Mainly because they are wanting a tool to accomplish a
> task.  If Gentoo can provide that tool, then getting it into the living  
> room
> wouldn't be a big deal.  As it is now, unfortunately, Gentoo is not  
> designed
> to be 'easy to use' in the sense of the average user's experience.  Once  
> it
> is, then it will be easier to market.  I like the ability to tinker with
> Gentoo, but I just wish it wasn't a requirement to use it.
>

I agree that a pretty good easy to use distribution for typical home users  
can be built with Gentoo. I do not care if it is built or not, but if it  
will make Gentoo more "healthy" or pleases Gentoo developers or Trustees  
in whatever way, I wish it is built. I do not want current Gentoo  
developers to spend their valuable time building such a distribution.

-- 
Andrei Gerasimenko
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] anti-portage wreckage?

[Aniruddha]

I am curious how these businesses manage their gentoo servers:

http://www.tek.net/

http://www.sevenl.net/
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] anti-portage wreckage?

[Neil Walker]

Aniruddha wrote:
> I am curious how these businesses manage their gentoo servers:
>
> http://www.tek.net/
>
> http://www.sevenl.net/
Hmm. I'm not entirely sure what you are asking. These companies offer 
Gentoo on a server on which the customer does the management. That's 
what  it means to  have a dedicated server - you  manage it.

 
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] anti-portage wreckage?

[Aniruddha]

here's another business based on gentoo:

http://www.inversepath.com/service-gentoo-support.html





-- 
gentoo-user@gentoo.org mailing list