[gentoo-dev] minimalistic emerge

[gentoo-dev] minimalistic emerge

[Igor]

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

Hi,

About 60% of all the packages are installed and work with nodep flag 
without any problems for years. Most of the maintainers just depend on new 
packages not knowing if it's necessary or not resulting in a really HUGE 
update that in the absolute majority of cases destabilize GENTOO making it 
not operational and WORSE than it was before. You then STABILIZE it again 
spending hours and then the story repeats itself.

Experience show that out of 20 new dependencies pulled by 
emerge only 1 is critical and really needed to assemble the target.

Is there any option in emerge to pull MINIMUM packages to 
get the result - install the application you need, leaving everything else 
AS IS untouched and stable?

I would rather prefer and many would agree to use this kind of 
install instead of a full system update by default.

Is there any USE flag that can switch system to this kind of update instead
of conventional? If no such USE flag, what about stabilize gentoo with 
STABILIZED flag implementation in make.conf?

Whoever needs everything new - can continue fighting with nature,
the rest of us who has a limited life span - well, they might go for 
STABILIZED flag and live happily ever after. 

What do you think?


-- 
Best regards,
 Igor                          mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Ciaran McCreesh]

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

On Fri, 8 Aug 2014 17:12:27 +0400
Igor <lanthruster@gmail.com> wrote:
> Is there any option in emerge to pull MINIMUM packages to 
> get the result - install the application you need, leaving everything
> else AS IS untouched and stable?

cave resolve --lazy :P

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] minimalistic emerge

[hasufell]

Igor:
> Hi,
> 
> About 60% of all the packages are installed and work with nodep flag 
> without any problems for years. Most of the maintainers just depend on new 
> packages not knowing if it's necessary or not resulting in a really HUGE 
> update that in the absolute majority of cases destabilize GENTOO making it 
> not operational and WORSE than it was before. You then STABILIZE it again 
> spending hours and then the story repeats itself.
> 
> Experience show that out of 20 new dependencies pulled by 
> emerge only 1 is critical and really needed to assemble the target.
> 
> Is there any option in emerge to pull MINIMUM packages to 
> get the result - install the application you need, leaving everything else 
> AS IS untouched and stable?
> 
> I would rather prefer and many would agree to use this kind of 
> install instead of a full system update by default.
> 
> Is there any USE flag that can switch system to this kind of update instead
> of conventional? If no such USE flag, what about stabilize gentoo with 
> STABILIZED flag implementation in make.conf?
> 
> Whoever needs everything new - can continue fighting with nature,
> the rest of us who has a limited life span - well, they might go for 
> STABILIZED flag and live happily ever after. 
> 
> What do you think?
> 
> 

Maybe try paludis.

It allows more fine-grained control over the dependency resolution process:
http://paludis.exherbo.org/clients/cave-resolve.html

Re: [gentoo-dev] minimalistic emerge

[Jeroen Roovers]

On Fri, 8 Aug 2014 17:12:27 +0400
Igor <lanthruster@gmail.com> wrote:

> About 60% of all the packages are installed and work with nodep flag 
> without any problems for years. Most of the maintainers just depend
> on new packages not knowing if it's necessary or not resulting in a
> really HUGE update that in the absolute majority of cases destabilize
> GENTOO making it not operational and WORSE than it was before. You
> then STABILIZE it again spending hours and then the story repeats
> itself.

Nice capitalisation! Speaking of which, where is the US$ 1,000,000
(ONE MILLION UNITED STATES DOLLARS) you promised in your last e-mail?

> Experience show that out of 20 new dependencies pulled by 
> emerge only 1 is critical and really needed to assemble the target.

Don't bother to file bug reports if you think a fully up to date system
is not for you.

> Is there any option in emerge to pull MINIMUM packages to 
> get the result - install the application you need, leaving everything
> else AS IS untouched and stable?

RTFM.

> Is there any USE flag that can switch system to this kind of update
> instead of conventional?

No. You're confusing USE flags with package manager features.

> If no such USE flag, what about stabilize
> gentoo with STABILIZED flag implementation in make.conf?

Next time, please bother the gentoo-user@ mailing list.


     jer

Re: [gentoo-dev] minimalistic emerge

[Alan McKinnon]

On 08/08/2014 15:32, Jeroen Roovers wrote:
>> If no such USE flag, what about stabilize
>> > gentoo with STABILIZED flag implementation in make.conf?
> Next time, please bother the gentoo-user@ mailing list.

No, please don't.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Hello Ciaran,

Friday, August 8, 2014, 5:22:03 PM, you wrote:

>> get the result - install the application you need, leaving everything
>> else AS IS untouched and stable?

> cave resolve --lazy :P

A great option name :-) I liked it. Wish it were there. 

Updating only the minimum necessary packages required is natural, wide
system update is a wrong math model. There are regulations 
in avionics, cybernetics and other life sensitive construction bureaus 
prohibiting system wide updates. BTW - directly follows from nature. 

Any complex bird is not updated on daily basis, it takes small steps, 
small changes targeting only small fixes - natures is adaptive and 
doesn't know where to move, it probes carefully, always backups, always
reversible, moves forward but very accurately, if the change 
in a bird is deep the chance is that it will stop functioning and die - for 
nature that means millions of years of genome programming is wasted. Whew, 
a lot of work.

NATURE is VERY lazy, and that's why I liked your option name a lot :-) you 
nailed it. 

From Cybernetics: 

Laziness is a built in algorithm. It controls system resources in case there 
is no threat to the system purposes with higher priorities. In other words - 
if what you're doing right now is well adopted to fulfill hard-coded in 
genome high priority purposes - there IS NO NEED TO CHANGE anything. 


GENTOO (and many other systems) in many ways violate the profound nature 
laws found out by venerable scientists, therefore what is done in long 
perspective is futile, it's more like painting the grass. 
You need 100 times more effort and resources to keep grass painted, each 
time you paint - a system wide update happens which is then REVERSED by nature. 
May be not a good example - but reflecting. 

One of the main built-in by nature perceptions of what is RIGHT or WRONG in human Genmoe
is time. After all our lifes are limited and the most precious what we have 
is time. 

Returning to our programming. 

Anything what is designed by a programmer for a user should be first evaluated from 
the time users spends. In fact you have no control over it - as a programmer you either 
accept it or leave the trade. If user feels he spends time - the project is a failure.

Anything you ever design - should require no time for a user to achieve the 
result. And finding and accessing what eats time is the virtue a talented programmer
has. 

Those are problems we face with GENTOO design if only the team could clearly state 
the problems and shift focus on their solution - GENTOO would be the greatest system 
ever. 

BUT 

From Cybernetics: 

As the environment changes - most systems are designed to adopt. Meaning there are many alternative 
systems solving differently same tasks, not VERY differently but differently enough to function 
in a situation where another system would cease. Many variants of the same system with variations exist 
in nature.

That what keeps is pulling in different directions, we're moving somewhere as most of us are not 
aware of deep algorithms inside of us which rules us so subtly. 

The nature is the greatest system designer, we all have to learn from it. 

PS 

Jeroen knows an option, but he won't tell - he is from 
GENTOO bug tracking service - no one can stand bug tracking for 
more than 1 year and he is there for more than 5, so you reckon..
he is probably reading this right now - try to be very quiet...

-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[hasufell]

Igor:
> Hello Ciaran,
> 
> Friday, August 8, 2014, 5:22:03 PM, you wrote:
> 
>>> get the result - install the application you need, leaving everything
>>> else AS IS untouched and stable?
> 
>> cave resolve --lazy :P
> 
> A great option name :-) I liked it. Wish it were there. 
> 

It is.

Re: [gentoo-dev] minimalistic emerge

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Igor - you need to read the emerge man page.

"emerge -uDNav @world" is the recommended way to update your system,
because then you will stay in sync with all appropriate updates in the
portage tree.  However, if you don't want to do this, just "emerge -u
@world" -- that will only update packages in your world file, and will
only force dependency updates when the new version is required (based
on minimum versions in package dependencies).  And if you only want to
upgrade things piecemeal, then use "--exclude [pkg]" to skip updates,
or "emerge -1 [pkg]" to only update an explicit list, or use
/etc/portage/package.mask to avoid updating to newer versions.

If you're asking for something even lighter than what 'emerge -u
@world' will provide, on an automagic system-wide level, then i think
you'll need to author some detailed specifications as to exactly what
it is you want this new updating feature to do.

Please note, though, that we as Gentoo developers can't guarantee that
your system is going to remain stable if you don't update --deep,
because we can't test every possible combination of every
stable-keyworded dependency version against every package -- not even
a tinderbox makes that particularly feasible, there's just too many
permutations.  I also am not sure at this time if 'emerge -u' would
upgrade dependencies when the version installed was removed from the
portage tree, and this may have multiple adverse effects on your
system long-term depending on why that older version was dropped from
the tree.

So, the recommendation remains that one should update the entire
system via -uDN in order to receive all of the updates available for
your entire dependency tree.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPk8LQACgkQ2ugaI38ACPA7KAEAgp2dnrl17tsbfWhejRW75/LB
Z46UnOotVyIQyoVuQPkA/3AQ4NtBE6R216mtFSwj/8xSetNkKnCx3gBxe6vCJt8T
=Eq1Y
-----END PGP SIGNATURE-----

Re: [gentoo-dev] minimalistic emerge

[Kent Fredric]

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

On 9 August 2014 01:12, Igor <lanthruster@gmail.com> wrote:

> Most of the maintainers just depend on new
> packages not knowing if it's necessary or not resulting in a really HUGE
> update that in the absolute majority of cases destabilize GENTOO making it
> not operational and WORSE than it was before. You then STABILIZE it again
> spending hours and then the story repeats itself.


Some of your assumptions seem misguided.

Some cases, dependencies are forward specifications from upstream telling
us what their software needs to function properly. Failing to meet that
requirement could void our support warranty from upstream.

Likewise, using 'nodeps' voids your support warranty from gentoo.

And just because "it works for me" that doesn't mean its not broken, it
just means you've not encountered the broken scenario that the dependencies
exist to guard against.

Very often upstream will discover a case where X doesn't work in 10% of the
problem space.

There's no way to communicate to a user what you will and will not do with
the software, so its impossible to know what flaws you will and won't
encounter, so the dependencies thus declare a minimum for expected working
behaviour for *all* a software's functionality, not just your user-specific
subset.

If you wish to override that decision, you may, but your self-supporting
from that point on.


TL;DR = just because it works /for you/, doesn't mean it /isn't broken/ and
doesn't mean the minimum declaration is "unnecessary" for all users.



-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

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

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Hello hasufell,

Friday, August 8, 2014, 7:36:24 PM, you wrote:


>>> cave resolve --lazy :P

>> A great option name :-) I liked it. Wish it were there. 

> It is.

Thanks!
I'll give cave a try. Never used it before. 



-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Hello Ian,

Friday, August 8, 2014, 7:45:56 PM, you wrote:


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256

> Igor - you need to read the emerge man page.

> "emerge -uDNav @world" is the recommended way to update your system,
> because then you will stay in sync with all appropriate updates in the
> portage tree.  However, if you don't want to do this, just "emerge -u
> @world" -- that will only update packages in your world file, and will
> only force dependency updates when the new version is required (based
> on minimum versions in package dependencies).  And if you only want to
> upgrade things piecemeal, then use "--exclude [pkg]" to skip updates,
> or "emerge -1 [pkg]" to only update an explicit list, or use
> /etc/portage/package.mask to avoid updating to newer versions.

It's unreliable, if you update system on daily basis - the system 
will get unstable and eventually will not even boot. It will be 
up-to-date but not functional. 
UDEV was the latest example :-( The updated system requires constant 
human assistance and the number of CRITICAL bugs is always 
constant (heart beat bug affected the latest systems but not old).
I know no server that is automatically updated with -uDNav @world 
and works for more than 6 months. 

I would do it but I know that each time @world updated - I'm in 
a possible trouble. I need to check all config files, all daemons 
for changes, boot managers, mdadmin, web servers, mysql, udev, 
and the surprise will happen when you boot next time. May be in 
in 300 days, then you try to remember what was changed in 
100 days, it's close to a hell.

Maintainers - don't have time to test packages against old 
versions, they just pull in the new versions in e-build with > 
each is doing that and the resulting update is an enormous 
surplus.

> If you're asking for something even lighter than what 'emerge -u
> @world' will provide, on an automagic system-wide level, then i think
> you'll need to author some detailed specifications as to exactly what
> it is you want this new updating feature to do.

> Please note, though, that we as Gentoo developers can't guarantee that
> your system is going to remain stable if you don't update --deep,
> because we can't test every possible combination of every
> stable-keyworded dependency version against every package -- not even
> a tinderbox makes that particularly feasible, there's just too many
> permutations.  I also am not sure at this time if 'emerge -u' would

You need to know what packages are installed and how they're installed 
world wide. That is the only way to stabilize Gentoo 
architecture. Firing updates not knowing what happened - is the lack 
of feedback that is hurting gentoo development. 

(of course all is IMHO) 

> upgrade dependencies when the version installed was removed from the
> portage tree, and this may have multiple adverse effects on your
> system long-term depending on why that older version was dropped from
> the tree.

> So, the recommendation remains that one should update the entire
> system via -uDN in order to receive all of the updates available for
> your entire dependency tree.

Is there any warranty that updated with -uDN system will remain 
full functional for 1 year? I have 100% warranty that not updated
system is going to remain functional for 5 or 6 years. I have some with 
7 years uptime. 

But if I'm going to update a SINGLE package on this system with --emerge 
it will pull EVERYTHING in, while nodep - may work fine. 

I'm in a trap - if I update daily - the systems are offline, I'm not able 
to maintain systems after updates - requires too much resources. If you have 
1 gentoo it might take a few days, imagine you have 100 or 1000 systems and 
they do not share the same hardware or the same boot locations, 
they all can be managed by 2 people if not updated and you need about 100 
people if you update. 

The number of bugs is the same. It's more difficult to hack into 1996 system 
than in 2012.

I'm very sorry may be I'm not getting it right, it hunts me how it's
advisable to update system daily and I'm having a very bad life experience 
out of advise. May be it's only me?

I can't keep a single system functional with auto-updates for just 6 months 
- something always breaks. For me Gentoo is not a toy, it's a tool I use 
daily. If a tool is broken - my product is broken.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2

> iF4EAREIAAYFAlPk8LQACgkQ2ugaI38ACPA7KAEAgp2dnrl17tsbfWhejRW75/LB
> Z46UnOotVyIQyoVuQPkA/3AQ4NtBE6R216mtFSwj/8xSetNkKnCx3gBxe6vCJt8T
> =Eq1Y
> -----END PGP SIGNATURE-----




-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Rich Freeman]

On Fri, Aug 8, 2014 at 11:45 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> However, if you don't want to do this, just "emerge -u
> @world" -- that will only update packages in your world file, and will
> only force dependency updates when the new version is required (based
> on minimum versions in package dependencies).

I'm not 100% certain, but I believe this will also update dependencies
if the currently-installed version is dropped from the repository.  On
the testing branch that happens a lot more often, but it will probably
happen on stable more often than perhaps Igor desires.

Keeping around package-versions that have been removed from the tree
is problematic for a few reasons:
1.  They could have security flaws and you'll never know.  Gentoo does
not issue security bulletins/etc for versions of packages no longer in
our repository.
2.  They could have compatibility issues and you'll never know.  If
foo v1,2,3 are in the tree and foo v1 doesn't work with bar, then bar
will have a >=foo-2 dependency.  If only foo v2 and 3 are in the tree
then the bar maintainer won't test it on v1, and won't exclude it from
the dependencies most likely.

This came up in the dynamic deps thread.  Setting aside all those
issues, suffice it to say that lots of bad things can go wrong when
you start keeping around packages or package-versions which aren't in
the tree.  We don't do releases like other distros, so old data gets
stale really fast.

Rich

Re: [gentoo-dev] minimalistic emerge

[Homer Parker]

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

On Fri, 2014-08-08 at 20:27 +0400, Igor wrote:
> I know no server that is automatically updated with -uDNav @world 
> and works for more than 6 months. 

	I would never auto-update.. That said, I installed this system in 2005.

> I can't keep a single system functional with auto-updates for just 6
> months 

	And that's why auto, unattended updates should never be used..

-- 
Homer Parker <hparker@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Kent,

Friday, August 8, 2014, 7:51:22 PM, you wrote:


There's no way to communicate to a user what you will and will not do with the software, so its impossible to know what flaws you will and won't encounter, so the dependencies thus declare a minimum for expected working behaviour for *all* a software's functionality, not just your user-specific subset.


Maintainers have no feedback from their ebuilds, they all do their best but there are no tools 
to formalize their work. No compass. They have no access to user 
space where the packages are installed, unaware how users are using their ebuilds. It's the design 
failure that hunts Gentoo from the start - no global intellectual bug tracking system. Doing not mistakes
- not possible, the automated tracking sub-systems should be there but... we are where we are. 

If the first portage had the stats in any shape Gentoo would be better now. A year ago I wanted to program it 
but I was in a very huge project that I'm still coding :-((( it's life or death project for me and I can't 
move out of it or I will sleep on a street. 

I appreciate all the work everyone is done on Gentoo in free time and I appreciate even more that you really found 
that time in this world and this life not saying but really doing. It's my best system and I only hope that someday 
I would be able to contribute to it as many of you did.



If you wish to override that decision, you may, but your self-supporting from that point on.


TL;DR = just because it works /for you/, doesn't mean it /isn't broken/ and doesn't mean the minimum declaration is "unnecessary" for all users. 


Agree. 

-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Hello Homer,

Friday, August 8, 2014, 8:40:20 PM, you wrote:

>> I know no server that is automatically updated with -uDNav @world 
>> and works for more than 6 months. 

>         I would never auto-update.. That said, I installed this system in 2005.

>> I can't keep a single system functional with auto-updates for just 6
>> months 

>         And that's why auto, unattended updates should never be used..

You're very brave saying it.
Cheers!


-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Kent Fredric]

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

On 9 August 2014 04:58, Igor <lanthruster@gmail.com> wrote:

> Maintainers have no feedback from their ebuilds, they all do their best
> but there are no tools
> to formalize their work. No compass. They have no access to user
> space where the packages are installed, unaware how users are using their
> ebuilds. It's the design
> failure that hunts Gentoo from the start - no global intellectual bug
> tracking system. Doing not mistakes
> - not possible, the automated tracking sub-systems should be there but...
> we are where we are.


Some of that is doable, ie: we could have installation metrics systems like
CPAN has a testers network with a matrix showing where a given thing is
failing : http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126

But its a lot of work investment to support.

And beyond "it installs" and "its tests pass", its piratically infeasible
to track software failing beyond there.

And some of the reasons we have dependency declarations are to avoid
problems that will ONLY be seen at runtime and WONT be seen during
installation or testing. ( Usually because the problem was found before
there were tests for it )

For that, only manual feedback systems, such as our present bugzilla, are
adequate.


-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

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

Re: [gentoo-dev] minimalistic emerge

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/08/14 12:27 PM, Igor wrote:
> Hello Ian,
> 
> Friday, August 8, 2014, 7:45:56 PM, you wrote:
> 
> 
> *> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
> 
>> Igor - you need to read the emerge man page.
> 
>> "emerge -uDNav @world" is the recommended way to update your
>> system, because then you will stay in sync with all appropriate
>> updates in the portage tree.  However, if you don't want to do
>> this, just "emerge -u @world" -- that will only update packages
>> in your world file, and will only force dependency updates when
>> the new version is required (based on minimum versions in package
>> dependencies).  And if you only want to upgrade things piecemeal,
>> then use "--exclude [pkg]" to skip updates, or "emerge -1 [pkg]"
>> to only update an explicit list, or use /etc/portage/package.mask
>> to avoid updating to newer versions.
> 
> *It's unreliable, if you update system on daily basis - the system
>  will get unstable and eventually will not even boot. It will be 
> up-to-date but not functional. UDEV was the latest example :-( The
> updated system requires constant human assistance and the number of
> CRITICAL bugs is always constant (heart beat bug affected the
> latest systems but not old). I know no server that is automatically
> updated with -uDNav @world and works for more than 6 months.
> 
> I would do it but I know that each time @world updated - I'm in a
> possible trouble. I need to check all config files, all daemons for
> changes, boot managers, mdadmin, web servers, mysql, udev, and the
> surprise will happen when you boot next time. May be in in 300
> days, then you try to remember what was changed in 100 days, it's
> close to a hell.

Of course.  Gentoo in and of itself does not provide a distro that is
out-of-the-box functioning at all times, like Debian or RHEL
does/tries-to*.  Updates do and always will require administrative
maintenance, emerge (and paludis and pkgcore) is not a tool that's
meant to be used in an automated fire-and-forget way, and the portage
tree doesn't provide packages in such a fashion either.  You will
always have to use your head when packages upgrade, as to the effect
that they will have on your system as a whole.

If you do want to push (server) updates in an automated way, then you
should have your own staging system that will build and host binpkg's,
including the necessary (manually vetted) configuration updates, and
have your servers pull those updates from the staging system.  That
way, you're still doing the due diligence that is required for updates
- -and- you have a means of rolling these updates out in a
mostly-automated fashion across multiple systems (whether they be
homogeneous or not).

[* this is only my perception of those projects, i have little
knowledge of them, and what knowledge i do have is a decade out-of-date]

> 
> Maintainers - don't have time to test packages against old 
> versions, they just pull in the new versions in e-build with > each
> is doing that and the resulting update is an enormous surplus.
> 

If a maintainer bumps the minimum version of an ebuild's dependencies,
then it's done so for a reason and this really shouldn't be
circumvented.  However, standard portage updates (via --deep) will
upgrade those dependencies to the latest stable in-tree version
regardless of what the minimum version is in the ebuild.  So the issue
that you seem to be complaining about here doesn't have anything to do
with maintainers and rather has to do with the way you're using emerge.


> *> If you're asking for something even lighter than what 'emerge
> -u
>> @world' will provide, on an automagic system-wide level, then i
>> think you'll need to author some detailed specifications as to
>> exactly what it is you want this new updating feature to do.
> 
>> Please note, though, that we as Gentoo developers can't guarantee
>> that your system is going to remain stable if you don't update
>> --deep, because we can't test every possible combination of
>> every stable-keyworded dependency version against every package
>> -- not even a tinderbox makes that particularly feasible, there's
>> just too many permutations.  I also am not sure at this time if
>> 'emerge -u' would
> 
> *You need to know what packages are installed and how they're
> installed world wide. That is the only way to stabilize Gentoo 
> architecture. Firing updates not knowing what happened - is the
> lack of feedback that is hurting gentoo development.
> 

What?  No.  We are not going to only commit new ebuilds (or only
stabilize ebuilds) for libraries on the basis of what versions other
distros are currently using as stable, and building their entire
package tree against.  If you want that, then what's the point of
using Gentoo in the first place?  Gentoo's strength is in its ability
to use arbitrary library versions (within certain restraints as
specified by their consumers) for any dependency, and update them as
new updates (with new features or bug fixes) are released upstream,
and rebuild (when necessary) the packages that depend on them, so that
you obtain and maintain an integrated system image.


> 
> *> upgrade dependencies when the version installed was removed from
> the
>> portage tree, and this may have multiple adverse effects on your 
>> system long-term depending on why that older version was dropped
>> from the tree.
> 
>> So, the recommendation remains that one should update the entire 
>> system via -uDN in order to receive all of the updates available
>> for your entire dependency tree.
> 
> *Is there any warranty that updated with -uDN system will remain 
> full functional for 1 year? I have 100% warranty that not updated 
> system is going to remain functional for 5 or 6 years. I have some
> with 7 years uptime.

If you -uDN daily/every other day/twice a week/weekly/monthly/whatever
*and* you *maintain* the system by doing the necessary configuration
changes and updates as you go, restarting services as necessary after
updates, etc. etc., then the system certainly can remain fully
functional.  You *do* have to -maintain- the systems though.  Read the
news items before updating so you know what configuration changes may
be expected of you, be proactive in putting those changes in place (or
push back some of those changes when they aren't necessary), pay
attention to what upgrades happen so that you arent blindly installing
a -major- package update (ie, a samba3 to samba4 type upgrade), and
you should be fine.

That said, no there is absolutely no warranty or guarantee.  Gentoo
does not provide a linux OS "appliance" -- it provides all the tools
an parts you need to build your own appliance with very little manual
intervention (compared to doing it all on your own), but the
management and maintenance of that appliance is in your hands.

It's like by-hand kernel updating -- yes, technically you could 'make
olddefconfig && make install && reboot' (or similar) blindly, but the
likliness of your system continuing to work optimally or even properly
gets pretty slim over time if you don't pay attention to how things
have changed from one version to the next.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPlCU4ACgkQ2ugaI38ACPCcugEAl558Gs6jdcHbeT5J46Ty38cN
eMeYa3MLIcUuhggUmW0A/0yGvjpaQeZaD15Owjit/27h9GzPSYaU8EMjlQn9W1ii
=nHCM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] minimalistic emerge

[Homer Parker]

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

On Fri, 2014-08-08 at 21:26 +0400, Igor wrote:
> Hello Homer,
> 
> Friday, August 8, 2014, 8:40:20 PM, you wrote:
> 
> >> I know no server that is automatically updated with -uDNav @world 
> >> and works for more than 6 months. 
> 
> >         I would never auto-update.. That said, I installed this system in 2005.
> 
> >> I can't keep a single system functional with auto-updates for just 6
> >> months 
> 
> >         And that's why auto, unattended updates should never be used..
> 
> You're very brave saying it.
> Cheers!
> 
> 

	No, I let the software do the work it's designed to do. Why would I
fight it?

-- 
Homer Parker <hparker@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] minimalistic emerge

[Peter Stuge]

Kent Fredric wrote:
> dependencies are forward specifications from upstream telling
> us what their software needs to function properly.

Unfortunately that's not the full story. :\

ebuilds often (for me) have artificial dependencies, when the actual
version required is too old to be in the tree, but maybe not too old
to be installed on an existing system.

I think it's bad policy to lie about dependencies in ebuilds for the
sole reason of only ever depending on versions which actually exist
in the same snapshot. It's a too simplistic model of reality.


//Peter

Re: [gentoo-dev] minimalistic emerge

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/08/14 03:34 PM, Peter Stuge wrote:
> Kent Fredric wrote:
>> dependencies are forward specifications from upstream telling us
>> what their software needs to function properly.
> 
> Unfortunately that's not the full story. :\
> 
> ebuilds often (for me) have artificial dependencies, when the
> actual version required is too old to be in the tree, but maybe not
> too old to be installed on an existing system.
> 
> I think it's bad policy to lie about dependencies in ebuilds for
> the sole reason of only ever depending on versions which actually
> exist in the same snapshot. It's a too simplistic model of
> reality.
> 

For the most part I don't think that happens very often; usually if
all stable versions of a dependency can satisfy a package's needs then
there isn't any minimum version specification (or the minimum version
specification hasn't actually been updated in an ebuild's *DEPEND,
despite the older versions having been removed).

The main exception to this is the work done related to gx86-multilib
(as for obvious reasons the multilib ebuilds are needed to supply
multilib dependencies), and the refactoring that mgorny did a few
weeks back to fix the EAPI<5 USE_EXPAND+IUSE_IMPLICIT undefined
behaviour issue.

That said, even if dependency atoms allow the older, no-longer-in-tree
versions to satisfy a package's needs, as I said earlier I don't think
any dev has the time and resources to test against anything older than
latest-stable, and definitely not anything that's no longer in the tree.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPlKW0ACgkQ2ugaI38ACPDAewD/ebk6WQa4pA4VJQkpiXf2Ch/R
uGz0HRy6/Y17eSxDL3wA/2gD8ciNsVWkIV6/kLGwwVXGItLL07A3OXITGLE1U8+N
=EBWi
-----END PGP SIGNATURE-----

Re: [gentoo-dev] minimalistic emerge

[Kent Fredric]

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

On 9 August 2014 07:34, Peter Stuge <peter@stuge.se> wrote:

> ebuilds often (for me) have artificial dependencies, when the actual
> version required is too old to be in the tree, but maybe not too old
> to be installed on an existing system.
>


The inverse is also true, sometimes you see people go:

"Well, upstream requires Foo 1.5 at least, but we have 2.0 as the oldest in
tree,
  so we can just say dev-whatever/Foo  and be done with it"

Which turns out to be horribly wrong if somebody still has Foo 1.4
installed, for whatever reason.

And this is just one reason why being excessively lazy about what you
upgrade could be secretly detrimental.


-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

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

Re: [gentoo-dev] minimalistic emerge

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/08/14 03:56 PM, Kent Fredric wrote:
> 
> On 9 August 2014 07:34, Peter Stuge <peter@stuge.se 
> <mailto:peter@stuge.se>> wrote:
> 
> ebuilds often (for me) have artificial dependencies, when the
> actual version required is too old to be in the tree, but maybe not
> too old to be installed on an existing system.
> 
> 
> 
> The inverse is also true, sometimes you see people go:
> 
> "Well, upstream requires Foo 1.5 at least, but we have 2.0 as the
> oldest in tree, so we can just say dev-whatever/Foo  and be done
> with it"
> 
> Which turns out to be horribly wrong if somebody still has Foo 1.4 
> installed, for whatever reason.
> 
> And this is just one reason why being excessively lazy about what
> you upgrade could be secretly detrimental.
> 

Also very true.

I don't think we have any sort of tree-wide policy on this either, do
we?  Although I believe common sense says it's a good idea (and i hope
most devs do this) to put a minver on a dependency atom if there was
any ebuild with an older version in the tree within the last year.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPlMC4ACgkQ2ugaI38ACPDUrgD+OiVN6HQKxNAOusj8PYI1O421
Dq2ihfhuQMz2HszG9DoBAJdTZJ9pRM6cFbkN+tcwFc/CAZUiWBe9MsSfoLkqho/C
=T+NJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Hello Kent,

Friday, August 8, 2014, 9:29:54 PM, you wrote:

But it's possible to fix many problems even now!

What would you tell if something VERY simple is implemented like - reporting 
every emerge failed due to slot conflict back home with details for inspection?

If maintainers had that kind of data then they could learn from the wild. I don't know what 
they would learn but I know it would be a very useful experience that might jump start 
evolution - useful updates to emerge and other tools. Almost every system designed by nature has 
feedback functions. It's the safe update - it will work even if not optimal from the start
or even if it's not clear what it will help to learn. The quality of ebuilds would improve too.

And from the useful life database new tools could evolve like - bug reporting automatization a 
whole new world of tool.

http://db.gentoo.org/report/

     System: System name 
       Arch: 
Package emerged: ....
Environment: ....
Dependency graph: .... -> ... -> ...
Fail message:

* 3 reports per day are accepted from one single IP
* no dups 

http://db.gentoo.org/stats/

- SlickGrid stats

Arch Package How many times Failed Fail message 

Click on Package -> Dependency Graph 

If GENTOO had everything emerging from any state (goal unattainable but desirable) that 
would be a great advantage for the users. That feel of a lean mean machine that saves time - it's 
tasty - new fans warranted.



On 9 August 2014 04:58, Igor <lanthruster@gmail.com> wrote:
Maintainers have no feedback from their ebuilds, they all do their best but there are no tools 
to formalize their work. No compass. They have no access to user 
space where the packages are installed, unaware how users are using their ebuilds. It's the design 
failure that hunts Gentoo from the start - no global intellectual bug tracking system. Doing not mistakes
- not possible, the automated tracking sub-systems should be there but... we are where we are. 
Some of that is doable, ie: we could have installation metrics systems like CPAN has a testers network with a matrix showing where a given thing is failing : http://matrix.cpantesters.org/?dist=CPAN-Meta-Requirements%202.126

But its a lot of work investment to support.

And beyond "it installs" and "its tests pass", its piratically infeasible to track software failing beyond there.

And some of the reasons we have dependency declarations are to avoid problems that will ONLY be seen at runtime and WONT be seen during installation or testing. ( Usually because the problem was found before there were tests for it )

For that, only manual feedback systems, such as our present bugzilla, are adequate. 


-- 
Kent 

KENTNL - https://metacpan.org/author/KENTNL





-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Johannes Huber]

Am Freitag 08 August 2014, 17:12:27 schrieb Igor:
> Hi,
> 
> About 60% of all the packages are installed and work with nodep flag
> without any problems for years. Most of the maintainers just depend on new
> packages not knowing if it's necessary or not resulting in a really HUGE
> update that in the absolute majority of cases destabilize GENTOO making it
> not operational and WORSE than it was before. You then STABILIZE it again
> spending hours and then the story repeats itself.
>
> Experience show that out of 20 new dependencies pulled by
> emerge only 1 is critical and really needed to assemble the target.
> 
> Is there any option in emerge to pull MINIMUM packages to
> get the result - install the application you need, leaving everything else
> AS IS untouched and stable?
> 
> I would rather prefer and many would agree to use this kind of
> install instead of a full system update by default.
> 
> Is there any USE flag that can switch system to this kind of update instead
> of conventional? If no such USE flag, what about stabilize gentoo with
> STABILIZED flag implementation in make.conf?
> 
> Whoever needs everything new - can continue fighting with nature,
> the rest of us who has a limited life span - well, they might go for
> STABILIZED flag and live happily ever after.
> 
> What do you think?

/me is thinking: 
 Your caps lock key is broken and about the content: man portage || use linux 
from scratch

-- 
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

Re: [gentoo-dev] minimalistic emerge

[Kent Fredric]

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

On 9 August 2014 08:52, Igor <lanthruster@gmail.com> wrote:

>  Hello Kent,
>
> Friday, August 8, 2014, 9:29:54 PM, you wrote:
>
> But it's possible to fix many problems even now!
>
> What would you tell if something VERY simple is implemented like -
> reporting
> every emerge failed due to slot conflict back home with details for
> inspection?
>
>
>
>
> *--  Best regards,  Igor                            *
> mailto:lanthruster@gmail.com <lanthruster@gmail.com>
>


Yes. As I said, INSTALLATION metrics reporting is easy enough to do.

I use those sorts of tools EXTENSIVELY with the CPAN platform, and I have
valuable reports on what failed, what the interacting components were, and
what systems the failures and passes occur on.

So I greatly appreciate this utility.

Automated bug reports however prove to be a waste of time, a lot of
failures are in fact entirely spurious as a result of user error.

So a metrics system that simply aggregates automated reports from end users
that is observed as a side channel to bugs, proves more beneficial in
reality.

Usually all maintainers need here is a daily or even weekly digest mail
summarising all the packages they're involved with, with their failure
summaries, with links to the failures. ( For example, here is one of the
report digests I received: http://i.imgur.com/WISqv15.png , and one of the
reports it links to :
http://www.cpantesters.org/cpan/report/ed7a4d9f-6bf3-1014-93f0-e557a945bbef
)

And for such, you don't need to apply rate limiting, because multiple
reports from a single individual prove to be entirely inconsequential, as
you're not forced to deal with them like normal bugs, but are simply out of
band feedback you can read when you have the time.

And you can then make sense of the content of that report using your inside
expertise and potentially file a relevant bug report based on extracted
information, or use context of that bug report to request more context from
its submitter.

But the point remains that this techology is _ONLY_ effective for install
time metrics, and is utterly useless for tracking any kinds of failures
that emanate from the *USE* of software.

If my firefox installation segv's, nothing is there watching for that to
file a report.

If firefox does something odd like renders characters incorrectly due to
some bug in GPU drivers ( actual issue I had once ), nothing will be
capable of detecting and reporting that.

Those things are still "bugs" and are still "bugs in packages" and still
"bugs in packages that can be resolved by changing dependencies", but are
however completely impossible to test for in advance of them happening as
part of the installation toolchain.

But I'm still very much on board with "have the statistics system". I use
it extensively, as I've said, and it is very much one of the best tools I
have for solving problems. ( the very distribution of the problems can
itself be used to isolate bugs.

For instance,
http://matrix.cpantesters.org/?dist=Color-Swatch-ASE-Reader%200.001000

Those red lights told me that I had a bug on platforms where perl floating
point precision is reduced

In fact, *automated* factor analysis pin pointed the probable cause faster
than I ever could:

http://analysis.cpantesters.org/solved?distv=Color-Swatch-ASE-Reader-0.001000

Just the main blockers are:

- Somebody has to implement this technology
- That requires time and effort
- People have to be convinced of its value
- Integration must happen at some level somehow somewhere in the portage
toolchain(s)
- People must opt in to this technology in order for the reports to happen
- And only then can this start to deliver meaningful results.



-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

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

Re: [gentoo-dev] minimalistic emerge

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/08/14 05:33 PM, Kent Fredric wrote:
> [ Snip! ] - Somebody has to implement this technology - That
> requires time and effort - People have to be convinced of its
> value - Integration must happen at some level somehow somewhere in
> the portage toolchain(s) - People must opt in to this technology in
> order for the reports to happen - And only then can this start to
> deliver meaningful results.
> 

*AND* (just to tie this back) it's unlikely that this is going to
actually help the original issue posted, ie, reducing the amount of
dependency updates being done "unnecessarily" on a system, or making
blind/automated system updates (of the type mentioned in the thread)
less susceptible to system breakage.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPlQ58ACgkQ2ugaI38ACPAXawEAplg4MCOXTmY+MxJ4FpCYLnJ8
j/ETs84sy7MreBlWHaEA/jH8dEyJlQ8QAnJDftxmgiySwogdBweYQgaL6gPkxJTJ
=Unnd
-----END PGP SIGNATURE-----

Re: [gentoo-dev] minimalistic emerge

[Kent Fredric]

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

On 9 August 2014 09:39, Ian Stakenvicius <axs@gentoo.org> wrote:

> *AND* (just to tie this back) it's unlikely that this is going to
> actually help the original issue posted, ie, reducing the amount of
> dependency updates being done "unnecessarily" on a system, or making
> blind/automated system updates (of the type mentioned in the thread)
> less susceptible to system breakage.
>

Yeah, if anything, that system is more likely to isolate previously unknown
incompatibilities, establish *tighter* dependency ranges in order to
satisfy them, and require *more* revision bumps and require you to update
much more than you already do.

So careful what you wish for :)


-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

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

Re: [gentoo-dev] minimalistic emerge

[Rich Freeman]

On Fri, Aug 8, 2014 at 4:16 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> I don't think we have any sort of tree-wide policy on this either, do
> we?  Although I believe common sense says it's a good idea (and i hope
> most devs do this) to put a minver on a dependency atom if there was
> any ebuild with an older version in the tree within the last year.

There is no reason not to specify a version constraint if you're aware of it.

However, I wouldn't expect devs to go digging around in cvs for
year-old package versions to test against them.  If upstream happens
to say it requires foo-1.5, by all means just take their word for it
and list it, but more often than not they don't bother to test old
versions either or note when the APIs they use were introduced.

Rich

[gentoo-dev] Re: minimalistic emerge

[Duncan]

Igor posted on Fri, 08 Aug 2014 17:12:27 +0400 as excerpted:

> About 60% of all the packages are installed and work with nodep flag
> without any problems for years. Most of the maintainers just depend on
> new packages not knowing if it's necessary or not resulting in a really
> HUGE update that in the absolute majority of cases destabilize GENTOO
> making it not operational and WORSE than it was before. You then
> STABILIZE it again spending hours and then the story repeats itself.
> 
> Experience show that out of 20 new dependencies pulled by emerge only 1
> is critical and really needed to assemble the target.
> 
> Is there any option in emerge to pull MINIMUM packages to get the result
> -
> install the application you need, leaving everything else AS IS
> untouched and stable?
> 
> I would rather prefer and many would agree to use this kind of install
> instead of a full system update by default.
> 
> Is there any USE flag that can switch system to this kind of update
> instead of conventional? If no such USE flag, what about stabilize
> gentoo with STABILIZED flag implementation in make.conf?
> 
> Whoever needs everything new - can continue fighting with nature,
> the rest of us who has a limited life span - well, they might go for
> STABILIZED flag and live happily ever after.
> 
> What do you think?

The above reads to me like gentoo is an inappropriate distribution for 
your use.  Gentoo doesn't claim to be all things to all people, and 
there's no shame for either gentoo or a user in a user switching to 
something else if gentoo simply doesn't match their needs.

In general, gentoo strongly emphasizes a number of things, including:

1) Rolling updates.  Install once, run for years doing frequent 
incremental updates.

2) Staying /relatively/ current.  For many packages, Gentoo removes older 
versions from the tree relatively quickly, certainly compared to the 
distros listed below, and once it's no longer in-tree, there's zero gentoo 
support for it -- you're on your own.

3) Build from source.  Gentoo does have rather limited binary-package 
support, but it remains fairly rudimentary, and the general assumption is 
that binary packages are locally built and distributed, not as part of 
the distribution.  (Tho at least in the past there have been binary-
package ISOs distributed, but without regular update and with Gentoo's 
relatively rapid update cycle they're outdated rather quickly.  I really 
don't know if there's current binpkg ISOs available or not.)

3a) There are, however, some independent gentoo-based distros that are 
binary-based, at least one of which allow more or less seamless switching 
between gentoo's source-based ebuilds and their binary-based packages.  
Tho I don't know of any long-term-support distros doing this.

Get outside of those norms and while gentoo may work, there's likely some 
other distribution that will work better.

If you only want to update the minimum necessary, and in particular, if 
you're keeping versions that have been removed from the tree, then 
something with a *MUCH* slower update cadence, where people sticking to 
versions that work for years at a time regardless of possible updates, is 
far more likely to match your needs.  Among the possibilities are:

Red Hat (RHEL) and clones: CentOS, Scientific Linux, Oracle's Linux 
(forgot the name ATM).

Red Hat is the gold standard, very long term commercial support, IIRC 10 
years, and very good community relations as they employ many of the 
developers on a number of core Linux upstream projects.  Oracle's Linux 
is commercial too, and is said to undercut RH in price, but has rather 
horrible community relations.  CentOS and Scientific Linux more community 
oriented and supported, free to install and update.  CentOS is now 
directly supported by Red Hat as a community version much like Fedora, 
only unlike Fedora, CentOS is a direct RHEL clone and long-term 
supported.  Scientific Linux is an independent RHEL clone, I believe 
primarily developed as the platform CERN standardizes on.

Debian: Stable and old-stable.

100% community distribution with an emphasis on free as in freedom.  
Larger than most, certainly larger than gentoo.  With a rather long 
release cycle and stable and old-stable, the support term is extended, 
but I don't believe it reaches that of Red Hat.

Since I strongly believe in both software freedom and in the free and 
open source software community, this would probably be my choice if I 
needed longer term version stability and support.  (FWIW, Arch Linux 
would probably be my choice for rapid-update, rolling-update, binary-
core, source-based extra packages, distro, but that's not the focus of 
this thread and thus not on this list or mentioned elsewhere in this 
post.)

Ubuntu LTS editions.

Quite popular, longer term commercial support available, but Ubuntu/
Canonical do sometimes have somewhat contentious community relations and 
go their own way on some projects, with little non-Ubuntu/Canonical 
uptake.  I'm not sure of the support term but I think it's three years 
full support on the LTS editions, 7-year extended.

SuSE: SLED/SLES.

I don't know so much about these.  The OpenSuSE community edition seems 
to be well received, but of course doesn't have the longer term support 
of the commercial editions.  Corporate ownership changed a few years ago 
and I know little of the new owners, but they do appear to be continuing 
active community involvement and project support (KDE, etc).  Seems to be 
more popular in Europe and especially Eastern Europe than in the US, tho 
some US retailers have standardized on it for what amounts to locked-down 
kiosk and register type systems with outsourced maintenance and 
effectively zero local store user control.

Those are all binary distros.  If you want from-source and are willing to 
do more of your own support, there's

Linux From Scratch (LFS)

AFAIK this is 100% community and primarily consists of a maintained set 
of instructions for doing your own builds from sources in the common LFS 
context.  It's thus less automated than gentoo, comparing to gentoo much 
like gentoo compares to the binary distros.  But since you're doing all 
the building yourself, simply following the LFS instructions, you get to 
choose what and when to update on your OWN schedule.  To my knowledge, 
there isn't a whole lot of support, but it doesn't really need it, since 
it's primarily a set of build instructions.  You'd be on your own in 
terms of updates and security tracking, presumably being able to follow 
the same instructions for newer versions of individual packages for 
awhile, but at some point, you'd either migrate beyond the LFS context as 
the instructions you originally followed would no longer apply, or you'd 
need to grab a new set of release instructions and install again, using 
them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] minimalistic emerge

[Peter Stuge]

Rich Freeman wrote:
> If upstream happens to say it requires foo-1.5, by all means just
> take their word for it and list it,

Don't take their documentation's word for it however, but look at
what the build actually requires. (E.g. configure.ac.)


//Peter

Re: [gentoo-dev] Re: minimalistic emerge

[Peter Stuge]

Duncan wrote:
> Red Hat is the gold standard, very long term commercial support,
> IIRC 10 years, and very good community relations

I've heard this on occasion, but reality is actually quite different.

Red Hat is a software service provider. They do whatever their paying
customers ask for. They do not take community relations very seriously
in my experience. I believe it is the job of a single person.


//Peter

Re: [gentoo-dev] minimalistic emerge

["Paweł Hajdan, Jr."]

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

On 8/8/14, 6:27 PM, Igor wrote:
>> Is there any warranty that updated with -uDN system will remain 
>> full functional for 1 year? I have 100% warranty that not updated
>> system is going to remain functional for 5 or 6 years. I have some with 
>> 7 years uptime. 

I'd say there is no "warranty". However, a staging environment can help
detecting issues earlier, before deploying them to production and
allowing you to come up with a way to address them.

I certainly wouldn't recommend just running an update on a running
production server without testing it first.

>> I'm in a trap - if I update daily - the systems are offline, I'm not able 
>> to maintain systems after updates - requires too much resources. If you have 
>> 1 gentoo it might take a few days, imagine you have 100 or 1000 systems and 
>> they do not share the same hardware or the same boot locations, 
>> they all can be managed by 2 people if not updated and you need about 100 
>> people if you update. 

Consider automating the processes - as you pointed out, the way
described above doesn't scale.

Possibly relevant article would be
<http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html>

>> The number of bugs is the same. It's more difficult to hack into 1996 system 
>> than in 2012.

Do you have any evidence to back that claim? There are tons of known
vulnerabilities in '96-era software, and automated exploits for them.

By the way, I can see a point in your thread. Our updates and package
manager could be improved. They have improved greatly in the last few
years. I think I can safely say we welcome further contributions of
patches, packaging and testing effort, especially helping automate many
of these tasks.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

[gentoo-dev] Re: minimalistic emerge

[Duncan]

Peter Stuge posted on Sat, 09 Aug 2014 10:34:58 +0200 as excerpted:

> Duncan wrote:
>> Red Hat is the gold standard, very long term commercial support,
>> IIRC 10 years, and very good community relations
> 
> I've heard this on occasion, but reality is actually quite different.
> 
> Red Hat is a software service provider. They do whatever their paying
> customers ask for. They do not take community relations very seriously
> in my experience. I believe it is the job of a single person.

I guess I was using a rather broader definition of "community relations" 
than that.

Red Hat directly employs a decent number of people working on various 
core Linux projects, benefiting not just Red Hat but the entire Linux and 
often the entire FLOSS (BSDs, etc included) community.  That's the sort 
of "community relations" I had in mind, not just what one or more people 
in a single RH department do.

I haven't actually counted all the upstream projects they either sponsor 
monetarily and with conferences, etc, or directly contribute employees 
to, but it's definitely non-trivial.  Were Red Hat to disappear, a lot of 
people would be looking for other employment and a lot of conferences 
would be looking for other high-level sponsors.  Not that they couldn't 
find it, but it's certainly leave a big hole until things settled down, 
that's for sure.

Take a look at the per-release LWN kernel activity statistics, for 
instance.  Red Hat is always ranked pretty high.  I know they're also 
involved in gnome and in systemd, and believe they're involved in various 
other freedesktop.org projects as well.  This is all community relations 
and involvement, far ahead of what most other commercial distros provide, 
and unlike say Ubuntu with its pretty-much Ubuntu-only Unity and Mir 
projects (compare gnome3 and wayland), Red Hat apparently sees value in 
working WITH the broader FLOSS community rather than going its own way.

In fact, their broad level of sponsorship within the community is 
sometimes seen as driving Red Hat focus to the exclusion of other 
distros, and indeed there may be a bit of truth to that, but compare the 
Red Hat approach to that of Ubuntu with Mir and Unity, and I doubt you'll 
find many wishing for more Ubuntus, while more Red Hats could only 
benefit the community by broadening its focus and making it less 
singularly Red Hat focused.

And they've always encouraged community-driven Red Hat clones as well, 
even sponsoring CentOS now, along with Fedora, as I said earlier.  
Compare that with say Oracle as a corporate parent and what they did to 
the various projects they inherited from Sun, including OpenSolaris, 
OpenOffice.org, MySQL...

I'm not saying Red Hat doesn't have corporate profit as a motive, but 
unlike many other corporate "friends" where the saying about who needs 
enemies with friends like that often rings true, Red Hat has anything but 
the "embrace and extinguish" reputation various others have gotten over 
the years.  They really /do/ seem to "get it" that a healthy FLOSS 
community really is in their best interest as well, and their actions, 
sponsorships and direct employee paychecks continue to demonstrate it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: minimalistic emerge

[hasufell]

Duncan:
> Peter Stuge posted on Sat, 09 Aug 2014 10:34:58 +0200 as excerpted:
> 
>> Duncan wrote:
>>> Red Hat is the gold standard, very long term commercial support,
>>> IIRC 10 years, and very good community relations
>>
>> I've heard this on occasion, but reality is actually quite different.
>>
>> Red Hat is a software service provider. They do whatever their paying
>> customers ask for. They do not take community relations very seriously
>> in my experience. I believe it is the job of a single person.
> 

[...]

Can you open a new thread about redhat? I fail to see any connection to
the initial issue.

Re: [gentoo-dev] Re: minimalistic emerge

[Ambroz Bizjak]

Hey all.

Regarding updates breaking the system, NixOS might be worth a try.
The functional nature of the package manager there lets you try out an
update, either live or in a VM, as well as roll back to the old
configuration in case of problems. Due to the design there's no risk
in building updates on a stable system, the build process won't
interfere until all the updates are built and you decide to try it out
in some way (other by exhausting RAM etc).
They also have both stable release branches and a master branch with
more updated packages.

(Not trying to start a distro war, please excuse me if it sounds like this.)

Best regards,
Ambroz

On Sat, Aug 9, 2014 at 1:06 PM, hasufell <hasufell@gentoo.org> wrote:
> Duncan:
>> Peter Stuge posted on Sat, 09 Aug 2014 10:34:58 +0200 as excerpted:
>>
>>> Duncan wrote:
>>>> Red Hat is the gold standard, very long term commercial support,
>>>> IIRC 10 years, and very good community relations
>>>
>>> I've heard this on occasion, but reality is actually quite different.
>>>
>>> Red Hat is a software service provider. They do whatever their paying
>>> customers ask for. They do not take community relations very seriously
>>> in my experience. I believe it is the job of a single person.
>>
>
> [...]
>
> Can you open a new thread about redhat? I fail to see any connection to
> the initial issue.
>

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Hello Kent,

Saturday, August 9, 2014, 1:33:30 AM, you wrote:


Yes. As I said, INSTALLATION metrics reporting is easy enough to do. 

I use those sorts of tools EXTENSIVELY with the CPAN platform, and I have valuable reports on what failed, what the interacting components were, and what systems the failures and passes occur on.

So I greatly appreciate this utility.

Automated bug reports however prove to be a waste of time, a lot of failures are in fact entirely spurious as a result of user error.

So a metrics system that simply aggregates automated reports from end users that is observed as a side channel to bugs, proves more beneficial in reality.

Usually all maintainers need here is a daily or even weekly digest mail summarising all the packages they're involved with, with their failure summaries, with links to the failures. ( For example, here is one of the report digests I received: http://i.imgur.com/WISqv15.png , and one of the reports it links to : http://www.cpantesters.org/cpan/report/ed7a4d9f-6bf3-1014-93f0-e557a945bbef  )


It's exactly what I think is missing with portage.

Yes, CPAN was always reliable. Feedback stands for adaptation. 

Another thing to learn from PERL is command line bug reporting tool that reports bugs directly on 
their bug tracking website. A great tool, usually with Gentoo you go to support then you post 
emerge environment and answer questions which a reporting module launched locally knows better 
than you. That drives a lot of time out of bag tracking team - they always have to ask the same 
questions reporters miss. 



And for such, you don't need to apply rate limiting, because multiple reports from a single individual prove to be entirely inconsequential, as you're not forced to deal with them like normal bugs, but are simply out of band feedback you can read when you have the time.

And you can then make sense of the content of that report using your inside expertise and potentially file a relevant bug report based on extracted information, or use context of that bug report to request more context from its submitter.

But the point remains that this techology is _ONLY_ effective for install time metrics, and is utterly useless for tracking any kinds of failures that emanate from the *USE* of software.


True because what we address is portage stabilization, not the system. 
But portage hell accounts (my esteem) for about 80% of all Gentoo user problems. 

The system stabilization after updates could be improved if there is way to minimize dependencies i.e. 
- not to pull updates unless necessary for the target assembly.

In a long perspective - there might be ways to asses what happened after update on function level. 
For example if daemon didn't start after update - it's a clear indication that there is a problem at least 
with the backward compatibility. 

When an administrator troubleshoots system he follows an algorithm a pattern, it's a complex pattern 
but it could be programmed to some extent.



If my firefox installation segv's, nothing is there watching for that to file a report.

If firefox does something odd like renders characters incorrectly due to some bug in GPU drivers ( actual issue I had once ), nothing will be capable of detecting and reporting that.


Could be done but the effort is unreasonable.



Those things are still "bugs" and are still "bugs in packages" and still "bugs in packages that can be resolved by changing dependencies", but are however completely impossible to test for in advance of them happening as part of the installation toolchain.

But I'm still very much on board with "have the statistics system". I use it extensively, as I've said, and it is very much one of the best tools I have for solving problems. ( the very distribution of the problems can itself be used to isolate bugs. 

For instance, http://matrix.cpantesters.org/?dist=Color-Swatch-ASE-Reader%200.001000 


Very nice!



Those red lights told me that I had a bug on platforms where perl floating point precision is reduced

In fact, *automated* factor analysis pin pointed the probable cause faster than I ever could: 

http://analysis.cpantesters.org/solved?distv=Color-Swatch-ASE-Reader-0.001000


Great, once the stats are there, with growing experience new tools could be written to 
automatically analyze data and make decisions. 



Just the main blockers are:

- Somebody has to implement this technology
- That requires time and effort
- People have to be convinced of its value
- Integration must happen at some level somehow somewhere in the portage toolchain(s)
- People must opt in to this technology in order for the reports to happen
- And only then can this start to deliver meaningful results.



IMHO seriously, it could be done if ONLY portage dev team would implement 
an interface CAPABLE for HTTP reporting. Once the interface is there but turned off 
by default - server side statistics are feasible. Personally I don't see any future of 
this system unless it's coded in portage. Today - portage support without server side 
- tomorrow - server side. 


-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

On August 9, 2014 10:56:49 AM EDT, Igor <lanthruster@gmail.com> wrote:
 [snip]
>Just the main blockers are:
>
>- Somebody has to implement this technology
>- That requires time and effort
>- People have to be convinced of its value
>- Integration must happen at some level somehow somewhere in the
>portage toolchain(s)
>- People must opt in to this technology in order for the reports to
>happen
>- And only then can this start to deliver meaningful results.
>
>
>
>IMHO seriously, it could be done if ONLY portage dev team would
>implement 
>an interface CAPABLE for HTTP reporting. Once the interface is there
>but turned off 
>by default - server side statistics are feasible. Personally I don't
>see any future of 
>this system unless it's coded in portage. Today - portage support
>without server side 
>- tomorrow - server side. 

Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for "Portage QOS" or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking  for votes and permission and changes. Second, repeatedly saying "we should have (some feature)" doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere.

Chris Reffett

Re: [gentoo-dev] minimalistic emerge

[Igor]

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

Hello Paweł,

Saturday, August 9, 2014, 1:34:29 PM, you wrote:

> Possibly relevant article would be
> <http://www.site-reliability-engineering.info/2014/04/what-is-site-reliability-engineering.html>

>>> The number of bugs is the same. It's more difficult to hack into 1996 system 
>>> than in 2012.

> Do you have any evidence to back that claim? There are tons of known
> vulnerabilities in '96-era software, and automated exploits for them.

> By the way, I can see a point in your thread. Our updates and package
> manager could be improved. They have improved greatly in the last few
> years. I think I can safely say we welcome further contributions of
> patches, packaging and testing effort, especially helping automate many
> of these tasks.

In my experience - hacking into 96 system with a 0 door is much harder 
than in 2014. In most cases unless you're an expert on 96 software which 
is difficult nowadays due to human memory. To really break in you need to
reproduce server environment as close as possible or/and have a clear 
understanding how this particular software works. Try to assemble a 
96 system on modern hardware or assemble it as they were back in 96,
not all sources are online any longer, that is a hard job. 2014 systems 
are much easier to assemble and get a peek to the sources is a trifle.

As Linux software is open-source it's often easier to break in Linux 
than in Windows systems. The open source is only theoretically safer. 
Many belive that because the code is open - it's reviewed and checked 
and the number of critical bugs is low. But the reality is that there 
is usually no time to review code. Many modern software is very complex 
with millions lines and it's not realistic to check or 
understand how it works before you use it in your project. Tell me 
how many libraries that you use right now are reviewed by you personally? 
Not many. And that is a door that is NEVER going to be closed. There are
bugs, rest assured, if you pull any soft right now and spend time 
you will find them. If you have an expertise on cross platforms - you 
will find even more as developers used to focus on one platform the birth 
platform.

If you compare the number of bugs you find in 1996 software and in 2014 
- the numbers would approximately be the same.

Usually 1996 system is patched or protected against known issues and you 
have to deal with "unknown" which in case of 1996 is much harder.

Another weak link with open source is software developers. Many of them 
spend a lot of time on their software not always getting a fair monetary
reward. So if you a very shrewd and have resources - you go to developers 
and offer them money to introduce a subtle bug into the main tree. After 
the software is adopted then you have open doors in EVERY "updated" 
linux on the planet. 

Personally I belive Heart Bleed bug is one of such. You can never proof 
if the bug is artificial or not - how? 

The same true for Microsoft soft. You can basically go to a ntkernel 
developer offer him 500 000$ if have them and he would add a bug and 
explain you how to use it and you're everywhere :-) but this is usually 
the government's methods. They used to keep them secret. 

-- 
Best regards,
 Igor                            mailto:lanthruster@gmail.com

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

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

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



On August 9, 2014 10:56:49 AM EDT, Igor <lanthruster@gmail.com> wrote:
 [snip]
>Just the main blockers are:
>
>- Somebody has to implement this technology
>- That requires time and effort
>- People have to be convinced of its value
>- Integration must happen at some level somehow somewhere in the
>portage toolchain(s)
>- People must opt in to this technology in order for the reports to
>happen
>- And only then can this start to deliver meaningful results.
>
>
>
>IMHO seriously, it could be done if ONLY portage dev team would
>implement 
>an interface CAPABLE for HTTP reporting. Once the interface is there
>but turned off 
>by default - server side statistics are feasible. Personally I don't
>see any future of 
>this system unless it's coded in portage. Today - portage support
>without server side 
>- tomorrow - server side. 

Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for "Portage QOS" or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking  for votes and permission and changes. Second, repeatedly saying "we should have (some feature)" doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere.

Chris Reffett
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

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

On August 9, 2014 10:56:49 AM EDT, Igor <lanthruster@gmail.com> wrote:
[snip]
>Just the main blockers are:
>
>- Somebody has to implement this technology
>- That requires time and effort
>- People have to be convinced of its value
>- Integration must happen at some level somehow somewhere in the
>portage toolchain(s)
>- People must opt in to this technology in order for the reports to
>happen
>- And only then can this start to deliver meaningful results.
>
>
>
>IMHO seriously, it could be done if ONLY portage dev team would
>implement 
>an interface CAPABLE for HTTP reporting. Once the interface is there
>but turned off 
>by default - server side statistics are feasible. Personally I don't
>see any future of 
>this system unless it's coded in portage. Today - portage support
>without server side 
>- tomorrow - server side. 

Then write it. Portage's source is available to anyone. I remember that you were on this list earlier this year pushing for "Portage QOS" or something. Keep in mind what a significant number of people told you then: first, if you want to make some change, just do it and show us what you have, rather than asking for votes and permission and changes. Second, repeatedly saying "we should have (some feature)" doesn't work if the people who would do the work (the portage team) don't see value in it. From the general response on the list, I would say this is the case. This means that if you want the feature, write it and come back with an implementation, since complaining about it is getting you nowhere.

Chris Reffett

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

Re: [gentoo-dev] minimalistic emerge

[Chris Reffett]

On August 9, 2014 11:46:54 AM EDT, Chris Reffett <creffett@gentoo.org> wrote:
>On August 9, 2014 10:56:49 AM EDT, Igor <lanthruster@gmail.com> wrote:
>[snip]
>>Just the main blockers are:
>>
>>- Somebody has to implement this technology
>>- That requires time and effort
>>- People have to be convinced of its value
>>- Integration must happen at some level somehow somewhere in the
>>portage toolchain(s)
>>- People must opt in to this technology in order for the reports to
>>happen
>>- And only then can this start to deliver meaningful results.
>>
>>
>>
>>IMHO seriously, it could be done if ONLY portage dev team would
>>implement 
>>an interface CAPABLE for HTTP reporting. Once the interface is there
>>but turned off 
>>by default - server side statistics are feasible. Personally I don't
>>see any future of 
>>this system unless it's coded in portage. Today - portage support
>>without server side 
>>- tomorrow - server side. 
>
>Then write it. Portage's source is available to anyone. I remember that
>you were on this list earlier this year pushing for "Portage QOS" or
>something. Keep in mind what a significant number of people told you
>then: first, if you want to make some change, just do it and show us
>what you have, rather than asking for votes and permission and changes.
>Second, repeatedly saying "we should have (some feature)" doesn't work
>if the people who would do the work (the portage team) don't see value
>in it. From the general response on the list, I would say this is the
>case. This means that if you want the feature, write it and come back
>with an implementation, since complaining about it is getting you
>nowhere.
>
>Chris Reffett
Apologies for multiple emails getting sent, on a mobile connection here and it reported a failure to send. My bad.

Chris Reffett
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] minimalistic emerge

[Ciaran McCreesh]

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

On Sat, 09 Aug 2014 11:12:46 -0400
Chris Reffett <creffett@gentoo.org> wrote:
> Then write it. Portage's source is available to anyone.

It's quicker to start from scratch than to try to add things to
Portage's source...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] minimalistic emerge

[Jeroen Roovers]

On Sat, 09 Aug 2014 11:12:46 -0400
Chris Reffett <creffett@gentoo.org> wrote:

> Then write it.

I think he's still working on his "Portage QOS" project.

http://article.gmane.org/gmane.linux.gentoo.devel/89472/


     jer

[OT] Re: [gentoo-dev] minimalistic emerge

[Tom Wijsman]

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

On Sat, 9 Aug 2014 19:25:56 +0400
Igor <lanthruster@gmail.com> wrote:

> In my experience - hacking into 96 system with a 0 door is much
> harder than in 2014. In most cases unless you're an expert on 96
> software which is difficult nowadays due to human memory.

Why does one need to be an expert?

How about known and/or implemented exploits?

> To really break in you need to reproduce server environment as close
> as possible or/and have a clear understanding how this particular
> software works. Try to assemble a 96 system on modern hardware or
> assemble it as they were back in 96, not all sources are online any
> longer, that is a hard job. 2014 systems are much easier to assemble
> and get a peek to the sources is a trifle.

Why reproduce the environment?

Is the sources' availability the only factor?

> As Linux software is open-source it's often easier to break in Linux 
> than in Windows systems. The open source is only theoretically safer. 
> Many belive that because the code is open - it's reviewed and checked 
> and the number of critical bugs is low. But the reality is that there 
> is usually no time to review code. Many modern software is very
> complex with millions lines and it's not realistic to check or 
> understand how it works before you use it in your project. Tell me 
> how many libraries that you use right now are reviewed by you
> personally? Not many. And that is a door that is NEVER going to be
> closed. There are bugs, rest assured, if you pull any soft right now
> and spend time you will find them. If you have an expertise on cross
> platforms - you will find even more as developers used to focus on
> one platform the birth platform.

Can you back up that open source is theoretically safer / harder / ...?

It depends on how you look at the source code and binaries; having
either doesn't necessarily make it easier or harder to accomplish,
especially if you want to find run-time behavior to exploit.

You could scan through the source code looking for known errors or so;
however, the same is possible to do with the machine code. Both can be
done manually or automatically; whether it gets tedious to find, depends
on what it is exactly that you are trying to find and how you find it.

> If you compare the number of bugs you find in 1996 software and in
> 2014 
> - the numbers would approximately be the same.

That reads like a wild guess due to too much assumptions / conditionals.

> Usually 1996 system is patched or protected against known issues and
> you have to deal with "unknown" which in case of 1996 is much harder.

This also reads like a wild guess; words ending in -ly like "usually"
indicate that you're not sure about it and how much of it really is as
such, a more believable statement would read like "...% of the systems
in 1996 are ... [reference to research]".

> Another weak link with open source is software developers. Many of
> them spend a lot of time on their software not always getting a fair
> monetary reward. So if you a very shrewd and have resources - you go
> to developers and offer them money to introduce a subtle bug into the
> main tree. After the software is adopted then you have open doors in
> EVERY "updated" linux on the planet. 
> 
> Personally I belive Heart Bleed bug is one of such. You can never
> proof if the bug is artificial or not - how? 
>
> The same true for Microsoft soft. You can basically go to a ntkernel 
> developer offer him 500 000$ if have them and he would add a bug and 
> explain you how to use it and you're everywhere :-) but this is
> usually the government's methods. They used to keep them secret. 

Have you considered steady high incomes and the aftermath?

With a steady high income and a high level job as Microsoft kernel
developer, 500 000$ and the aftermath of consequences loses traction.

You might be able to convince that single kernel developer; however,
that developer still has to slip this by the rest of the kernel
development team as well as quality assurance processes and measures.

Getting by the static and dynamic analyzers as well as other run-time
measures they have to their availability for awareness is harder than
without it; apart from it, there's are also human code reviews and QA.

The story gets somewhat different when people don't end up using them,
or not spend an equivalent effort; like for example with Heart Bleed.

Think about some random unrelated pieces of open source libraries; did
that get run through analyzers and include run-time measures, have code
reviews like kernels would have and extended QA procedures?

https://i.imgflip.com/b3mx0.jpg

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] minimalistic emerge

[Tom Wijsman]

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

On Fri, 8 Aug 2014 15:32:37 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> Nice capitalisation! Speaking of which, where is the US$ 1,000,000
> (ONE MILLION UNITED STATES DOLLARS) you promised in your last e-mail?

Nice placement of the space behind the dollar sign! No money for you.

> Don't bother to file bug reports if you think a fully up to date
> system is not for you.

Where do we state to have a fully up-to-date system before filing a bug?

This in particular becomes interesting to do when the bug keeps you from
updating your system; or even further, rendering it non bootable.

We need to fix things such that people have a working system that they
can bring up-to-date; not the other way around, as that is pointless.

Automatic updates is a goal to pursue; well, at least if you want
everyone to have a fully up-to-date bootable system that can update.
 
> > Is there any option in emerge to pull MINIMUM packages to 
> > get the result - install the application you need, leaving
> > everything else AS IS untouched and stable?
> 
> RTFM.

Why do you point to a manual which does not document such feature?
 
> > If no such USE flag, what about stabilize
> > gentoo with STABILIZED flag implementation in make.conf?
> 
> Next time, please bother the gentoo-user@ mailing list.

No. The gentoo-user@ ML can't do anything about a missing feature.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] minimalistic emerge

[Tom Wijsman]

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

On Sat, 9 Aug 2014 18:10:51 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 09 Aug 2014 11:12:46 -0400
> Chris Reffett <creffett@gentoo.org> wrote:
> > Then write it. Portage's source is available to anyone.
> 
> It's quicker to start from scratch than to try to add things to
> Portage's source...

But do we want to be quicker? If you want a lot of input, Portage...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] minimalistic emerge

[Tom Wijsman]

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

On Fri, 08 Aug 2014 23:04:40 +0200
Johannes Huber <johu@gentoo.org> wrote:

> /me is thinking: 
>  Your caps lock key is broken and about the content: man portage ||
> use linux from scratch

Caps lock highlighting is a common practice. Why do you tell him to read
a manual or use a distribution that both lack the requested feature?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] minimalistic emerge

[hasufell]

Tom Wijsman:
> On Sat, 9 Aug 2014 18:10:51 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
>> On Sat, 09 Aug 2014 11:12:46 -0400
>> Chris Reffett <creffett@gentoo.org> wrote:
>>> Then write it. Portage's source is available to anyone.
>>
>> It's quicker to start from scratch than to try to add things to
>> Portage's source...
> 
> But do we want to be quicker? If you want a lot of input, Portage...
> 

How is your private PM project going? I heard you want to write a PM
from scratch in C++.