Re: [gentoo-portage-dev] [PATCH] emerge: add --search-fuzzy and --search-fuzzy-cutoff options (bug 65566)

[Zac Medico]

On 04/08/2016 04:33 AM, Alexander Berntsen wrote:
> On 08/04/16 08:21, Zac Medico wrote:
>> Reverse? You want it to measure dissimilarity? Not sure what you
>> mean.
> Sorry, I meant reverse the *docs* to mean "find things that are at
> least 50% similar" rather than "cut off things that aren't above the
> 0.5 threshold". I.e. use an inclusive sentence. I feel that this is
> more clear.
> 
>> I just want it to fail if the input is invalid.
> Yes, I just realised you checked if it were <=, not just <. I think
> this is a bad idea. It's easily missed -- I just missed it last time
> around. I would suggest to make it fail early, rather than set it to
> 0.0 which you then set to None. Just set it to None immediately.
> 

I've just sent "[PATCH] emerge: add --fuzzy-search and
--search-similarity (bug 65566)" which hopefully accounts for all of the
previous feedback.
-- 
Thanks,
Zac

[gentoo-portage-dev] [PATCH] emerge: add --fuzzy-search and --search-similarity (bug 65566)

[Zac Medico]

Add --fuzzy-search option, and --search-similarity option to adjust
the minimum similarity for search results (defaults to 80%).

X-Gentoo-bug: 65566
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=65566
---
 man/emerge.1   | 14 ++
 pym/_emerge/actions.py |  7 +--
 pym/_emerge/main.py| 32 +++-
 pym/_emerge/search.py  | 26 --
 4 files changed, 74 insertions(+), 5 deletions(-)

diff --git a/man/emerge.1 b/man/emerge.1
index da1d852..7442220 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -565,6 +565,14 @@ packages (fetch things from SRC_URI based upon USE 
setting).
 Instead of doing any package building, just perform fetches for all
 packages (fetch everything in SRC_URI regardless of USE setting).
 .TP
+.BR "\-\-fuzzy\-search [ y | n ]"
+Enable or disable fuzzy search for search actions. When fuzzy search
+is enabled, a result is returned if it is sufficiently similar to the
+search string, without requiring an exact match. This option is enabled
+by default. Fuzzy search does not support regular expressions, therefore
+it is automatically disabled for regular expression searches. Fuzzy
+search is slightly slower than non\-fuzzy search.
+.TP
 .BR "\-\-getbinpkg [ y | n ] (\-g short option)"
 Using the server and location defined in \fIPORTAGE_BINHOST\fR (see
 \fBmake.conf\fR(5)), portage will download the information from each binary
@@ -874,6 +882,12 @@ enabled by default. The search index needs to be 
regenerated by
 to \fBEMERGE_DEFAULT_OPTS\fR (see \fBmake.conf\fR(5)) and later
 overridden via the command line.
 .TP
+.BR "\-\-search\-similarity PERCENTAGE"
+Set the minimum similarity percentage (a floating-point number between
+0 and 100). Search results with similarity percentages lower than this
+are discarded (default: \'80\'). This option has no effect unless the
+\fB\-\-fuzzy\-search\fR option is enabled.
+.TP
 .BR "\-\-select [ y | n ] (\-w short option)"
 Add specified packages to the world set (inverse of
 \fB\-\-oneshot\fR). This is useful if you want to
diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
index 1dc2b0d..6704afc 100644
--- a/pym/_emerge/actions.py
+++ b/pym/_emerge/actions.py
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import division, print_function, unicode_literals
@@ -1974,7 +1974,10 @@ def action_search(root_config, myopts, myfiles, spinner):
spinner, "--searchdesc" in myopts,
"--quiet" not in myopts, "--usepkg" in myopts,
"--usepkgonly" in myopts,
-   search_index = myopts.get("--search-index", "y") != "n")
+   search_index=myopts.get("--search-index", "y") != "n",
+   search_similarity=myopts.get("--search-similarity"),
+   fuzzy=myopts.get("--fuzzy-search") != "n",
+   )
for mysearch in myfiles:
try:
searchinstance.execute(mysearch)
diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py
index 0e672a2..eae1954 100644
--- a/pym/_emerge/main.py
+++ b/pym/_emerge/main.py
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import print_function
@@ -141,6 +141,7 @@ def insert_optional_args(args):
'--deselect' : y_or_n,
'--binpkg-respect-use'   : y_or_n,
'--fail-clean'   : y_or_n,
+   '--fuzzy-search' : y_or_n,
'--getbinpkg': y_or_n,
'--getbinpkgonly': y_or_n,
'--jobs'   : valid_integers,
@@ -458,6 +459,11 @@ def parse_opts(tmpcmdline, silent=False):
"choices" : true_y_or_n
},
 
+   "--fuzzy-search": {
+   "help": "Enable or disable fuzzy search",
+   "choices": true_y_or_n
+   },
+
"--ignore-built-slot-operator-deps": {
"help": "Ignore the slot/sub-slot := operator parts of 
dependencies that have "
"been recorded when packages where built. This 
option is intended "
@@ -658,6 +664,12 @@ def parse_opts(tmpcmdline, silent=False):
"choices": y_or_n
},
 
+   "--search-similarity": {
+   "help": ("Set minimum similarity percentage for fuzzy 
seach "
+   "(a floating-point number between 0 and 100)"),
+   "action": "store"
+   },
+
"--select": {
"shortopt" : "-w",
 

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-07-24 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-07-24 23:59 UTC.

Removals:
app-cdr/dvd95  20160724-11:25 mgorny 37d88cd
app-portage/g-ctan 20160724-10:45 mgorny abca5f5
dev-libs/vdk   20160724-10:49 mgorny 0327e68
dev-ml/comparelib  20160724-11:27 mgorny de36366
dev-ml/deriving-ocsigen20160724-11:27 mgorny 7b64536
dev-ml/faillib 20160724-11:28 mgorny ec9de68
dev-ml/typehashlib 20160724-11:29 mgorny 7f9b715
dev-perl/class-loader  20160723-05:55 kentnl 25889f6
dev-perl/convert-ascii-armour  20160724-08:20 kentnl af57591
dev-util/as11  20160724-13:20 mgorny d401ba2
dev-util/ccmalloc  20160724-13:12 mgorny a852a18
dev-util/cdecl 20160724-13:13 mgorny 7c81cf8
dev-util/crow-designer 20160724-13:19 mgorny b5d75ae
dev-util/eggy  20160724-13:15 mgorny c39c653
dev-util/filepp20160724-13:20 mgorny a4806bf
dev-util/ghh   20160724-13:17 mgorny d001d70
dev-util/httpup20160724-13:19 mgorny 2d7cff1
dev-util/injectso  20160724-13:17 mgorny 86607f3
dev-util/intel2gas 20160724-13:19 mgorny 370481f
dev-util/jif   20160724-13:18 mgorny fe37fe4
dev-util/kdoc  20160724-13:20 mgorny fb3d9fe
dev-util/mock  20160724-13:16 mgorny caa827e
dev-util/par   20160724-13:17 mgorny e82ed77
dev-util/qdevelop  20160724-13:19 mgorny 4014383
dev-util/rec   20160724-13:18 mgorny eb1c720
dev-util/redet 20160724-13:14 mgorny 85e7208
dev-util/skelgen   20160724-13:21 mgorny 3c09719
dev-util/webcpp20160724-13:20 mgorny c0f8220
media-sound/trommler   20160724-10:42 mgorny 8b1a853
media-tv/dvbstreamer   20160724-10:49 mgorny 37719ef
media-tv/freevo20160724-10:47 mgorny a6016e4
media-video/avinfo 20160724-10:42 mgorny b8d7672
media-video/subotage   20160724-11:26 mgorny b0e2d94
net-misc/ksshaskpass   20160724-11:54 johu   7da846b
net-misc/mdidentd  20160720-16:45 kensington 8b872eb
net-p2p/microdc2   20160724-10:48 mgorny 8409aa2
sys-auth/pam_keystore  20160720-16:48 kensington 784a011
www-apache/mod-auth-mysql  20160724-10:46 mgorny 9d9536e
www-apache/mod_spdy20160724-10:35 mgorny bf50d4e
www-apps/trac-downloads20160724-10:37 mgorny 2b255cc
x11-apps/xkbset20160723-09:10 jerb63789e

Additions:
app-crypt/rhash20160721-10:35 monsieurp  5f22584
app-misc/tek   20160723-08:11 aidecoe8f079e5
dev-perl/Class-Loader  20160723-05:43 kentnl dacbbd7
dev-perl/Convert-ASCII-Armour  20160724-08:13 kentnl d4bcfc1
dev-ros/rosserial_tivac20160718-11:43 aballier   3581465
dev-ruby/curses20160723-18:12 graaff 59c2430
media-libs/libmypaint  20160718-15:25 sping  76d49b5
net-misc/socket-burst-dampener 20160720-10:15 zmedico6cd309c
x11-misc/qt5ct 20160720-17:45 monsieurp  4c01463
x11-misc/xkbset20160723-09:09 jer3c1142f

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
dev-util/skelgen,removed,mgorny,20160724-13:21,3c09719
dev-util/kdoc,removed,mgorny,20160724-13:20,fb3d9fe
dev-util/filepp,removed,mgorny,20160724-13:20,a4806bf
dev-util/as11,removed,mgorny,20160724-13:20,d401ba2
dev-util/webcpp,removed,mgorny,20160724-13:20,c0f8220
dev-util/intel2gas,removed,mgorny,20160724-13:19,370481f
dev-util/qdevelop,removed,mgorny,20160724-13:19,4014383
dev-util/crow-designer,removed,mgorny,20160724-13:19,b5d75ae
dev-util/httpup,removed,mgorny,20160724-13:19,2d7cff1
dev-util/jif,removed,mgorny,20160724-13:18,fe37fe4
dev-util/rec,removed,mgorny,20160724-13:18,eb1c720
dev-util/ghh,removed,mgorny,20160724-13:17,d001d70
dev-util/injectso,removed,mgorny,20160724-13:17,86607f3
dev-util/par,removed,mgorny,20160724-13:17,e82ed77
dev-util/mock,removed,mgorny,20160724-13:16,caa827e
dev-util/eggy,removed,mgorny,20160724-13:15,c39c653
dev-util/redet,removed,mgorny,20160724-13:14,85e7208
dev-util/cdecl,removed,mgorny,20160724-13:13,7c81cf8
dev-util/ccmalloc,removed,mgorny,20160724-13:12,a852a18
net-misc/ksshaskpass,removed,johu,20160724-11:54,7da846b
dev-ml/typehashlib,removed,mgorny,20160724-11:29,7f9b715
dev-ml/faillib,removed,mgorny,20160724-11:28,ec9de68
dev-ml/deriving-ocsigen,removed,mgorny,20160724-11:27,7b64536
dev-ml/comparelib,removed,mgorny,20160724-11:27,de36366
media-video/subotage,removed,mgorny,20160724-11:26,b0e2d94
app-cdr

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Kent Fredric]

On Sun, 24 Jul 2016 12:17:56 +0200
Michał Górny  wrote:

> So what's the alternative? Design another eclass where ebuilds will
> fail just the same because people will ignore the more explicit
> requirement just the same as they do ignore the API?

Sometimes you don't need a "new path", you just need to transition from
the old behaviour to the new behaviour at a slower rate with more
visibility.

Option 1: Start off with them being QA Warnings instead of fatal errors
and encourage end users to report them where they see them.

Then after a cycle of warnings, you go through and fatalise them
incrementally in order of "least likely to break the build in dangerous
ways". 

Option 2: Bind the behaviour to an EAPI version that is not yet in use.

Then, when that EAPI gets rolled out to the ebuilds getting upgrades,
the strictures come into effect when the EAPI changes, giving
maintainers fair opportunity to fix the problem before it rolls out to
users.

For me neither of these options say "don't do this thing", they're just
"manage the bleeding better"


pgp4LnC2rcpnQ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Alexis Ballier]

On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn  wrote:
> > Then ebuilds will fail just the same  
> 
> No. Before, ebuilds would maybe display an upgrading message when
> they shouldn't, or vice versa. Now the eclass dies on them.


As a side note: die-ing in anything after merging the package
(>=pkg_postinst) is a seriously bad idea.

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Chí-Thanh Christopher Nguyễn]

Chí-Thanh Christopher Nguyễn schrieb:

I don't say it is a correct use of versionator.eclass. I just say it has
become (unintentionally) part of the API, and therefore is subject to the
rules about changing APIs in eclasses.


Actually, after reading those rules[1] again, it would be enough to fix all 
ebuilds in the tree and wait 30 days to be in compliance with eclass policy.


So from my side I will no longer object to your proposed change, provided 
these conditions are met.



Best regards,
Chí-Thanh Christopher Nguyễn

[1] https://devmanual.gentoo.org/eclass-writing/

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Ulrich Mueller]

> On Sun, 24 Jul 2016, Michał Górny wrote:

> There is no such thing as 'unintentional API'. API is what's
> described. If you rely on internals, random undefined behaviors
> or whatever, it's not a part of the API.

Like memcpy(3) direction?

Ulrich


pgpaBBWxp15uE.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Jeroen Roovers]

On Sun, 24 Jul 2016 12:17:56 +0200
Michał Górny  wrote:

> But that's a social problem that could easily solved by more
> proactive retirements, and not a good API design point.

You need some trained and payed PR people to correct your writings
before they go to press or you will never be elected president.


 jer

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

You are changing the API of versionator.eclass, even if it was unintentional 
API.


There is no such thing as 'unintentional API'. API is what's described.
If you rely on internals, random undefined behaviors or whatever, it's
not a part of the API.


Well there is the API according to the docs, and then there is the API 
according to the implementation...



Then ebuilds will fail just the same


No. Before, ebuilds would maybe display an upgrading message when they
shouldn't, or vice versa. Now the eclass dies on them.


So what's the alternative? Design another eclass where ebuilds will
fail just the same because people will ignore the more explicit
requirement just the same as they do ignore the API?


I don't know what is your problem here. The eclass needs not be designed 
again from the ground up.
All ebuilds which are unaffected by bug 589444 can be switched to the new 
eclass/functions immediately. The others after they are changed no longer 
make the implicit assumption that REPLACING_VERSIONS contains only a single 
version.



The problem is not 'there is a valid case to pass useless parameters
to the function'. The problem is 'I make an invalid assumption about
what will happen based on my limited knowledge which I believe is
more correct than people who wrote package managers'.


I don't say it is a correct use of versionator.eclass. I just say it has 
become (unintentionally) part of the API, and therefore is subject to the 
rules about changing APIs in eclasses. I agree that relying on unintentional 
or undocumented API is bad and needs to be addressed.



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Michał Górny]

On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn  wrote:

> Michał Górny schrieb:
> > So, to summarize we shouldn't fix existing code because people did
> > assume accepting invalid parameters was fine.  
> 
> You are changing the API of versionator.eclass, even if it was unintentional 
> API.

There is no such thing as 'unintentional API'. API is what's described.
If you rely on internals, random undefined behaviors or whatever, it's
not a part of the API.

Yes, I know that most of Gentoo developers are bright enough to assume
'if it is not explicitly forbidden in words I can't find a way to bend
to pretend it's allowed anyway, it's allowed even if it doesn't make
any sense'. But that's a social problem that could easily solved by more
proactive retirements, and not a good API design point.

> > Then ebuilds will fail just the same  
> 
> No. Before, ebuilds would maybe display an upgrading message when they 
> shouldn't, or vice versa. Now the eclass dies on them.

So what's the alternative? Design another eclass where ebuilds will
fail just the same because people will ignore the more explicit
requirement just the same as they do ignore the API?

The problem is not 'there is a valid case to pass useless parameters
to the function'. The problem is 'I make an invalid assumption about
what will happen based on my limited knowledge which I believe is
more correct than people who wrote package managers'.

-- 
Best regards,
Michał Górny



pgpQTqIRQWLXO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Jason Zaman]

On Sun, Jul 24, 2016 at 10:17:24AM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
> > So, to summarize we shouldn't fix existing code because people did
> > assume accepting invalid parameters was fine.
> 
> You are changing the API of versionator.eclass, even if it was unintentional 
> API.

# @FUNCTION: version_is_at_least
# @USAGE:  [have]
# @DESCRIPTION:
# Is $2 (defaults to $PVR) at least version $1? Intended for use in eclasses
# only. May not be reliable, be sure to do very careful testing before actually
# using this.

The API seems pretty clear to me ...

-- Jason

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Chí-Thanh Christopher Nguyễn]

Ciaran McCreesh schrieb:

On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn  wrote:

Then ebuilds will fail just the same


No. Before, ebuilds would maybe display an upgrading message when
they shouldn't, or vice versa. Now the eclass dies on them.


This attitude that invisible failures (which don't get fixed, and which
lead to occasional weirdness) are better than visible failures (which
must be fixed) is an odd one... Postel has a lot to answer for.


I would agree with you when it comes to upstreams' -Werror but I do realize 
that I am in the minority there.


My point here is that this change will affect the behaviour of ebuilds using 
this eclass.



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Ciaran McCreesh]

On Sun, 24 Jul 2016 10:17:24 +0200
Chí-Thanh Christopher Nguyễn  wrote:
> > Then ebuilds will fail just the same  
> 
> No. Before, ebuilds would maybe display an upgrading message when
> they shouldn't, or vice versa. Now the eclass dies on them.

This attitude that invisible failures (which don't get fixed, and which
lead to occasional weirdness) are better than visible failures (which
must be fixed) is an odd one... Postel has a lot to answer for.

-- 
Ciaran McCreesh

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:

So, to summarize we shouldn't fix existing code because people did
assume accepting invalid parameters was fine.


You are changing the API of versionator.eclass, even if it was unintentional 
API.


Then ebuilds will fail just the same


No. Before, ebuilds would maybe display an upgrading message when they 
shouldn't, or vice versa. Now the eclass dies on them.



Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] [PATCH] versionator.eclass: Add tests for parameter counts

[Michał Górny]

On Sun, 24 Jul 2016 00:17:21 +0200
Chí-Thanh Christopher Nguyễn  wrote:

> Michał Górny schrieb:
> > Ensure that proper number of parameters is passed to each versionator
> > function; die otherwise. This prevents the functions from proceeding
> > with undefined behavior when mis-called.  
> 
> You are making what versionator.eclass accepts stricter. That it used to work 
> when passed multiple versions may be unintentional, but I think you need to 
> introduce a new eclass or new function names in this case.

So, to summarize we shouldn't fix existing code because people did
assume accepting invalid parameters was fine.

What we should do instead is create an almost identical copy of it, ask
people to switch to new code with parameter checks. But... why?

If people already pass valid parameters, then new and old code would be
functionally identical. If they do not, then they can fix parameters
and stay with the old code. But they shouldn't have been doing that in
the first place...

So in the end, we create another copy of the functions that's used
inconsistently with the old copy, and only when people feel like
switching. Then ebuilds will fail just the same because people wouldn't
care to *ensure* they pass valid parameters while switching, as long as
they won't trigger it on their limited test case...

-- 
Best regards,
Michał Górny



pgpUMSncJP8S8.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Ciaran McCreesh]

On Sun, 24 Jul 2016 10:05:23 +0300
Andrew Savchenko  wrote:
> I agree with you, but REPLACING_VERSIONS has nothing to do with
> such recovery.

Yes, it does. Specifically, what we want is for developers to get into
the habit of writing safe, clean code, even if they think they don't
need to care about it in some particular situation because they can't
think of how it would go wrong. It's the same as getting into the habit
of sticking || die on things.

> 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
> from hardware crashes forked well long before.

Before this, you could use has_version in pkg_*, and it would tell you
the *old* version of the package that was installed. The phase order
changed a while ago, and broke this, so REPLACING_VERSIONS was the
replacement.

Again, the situation is complicated, there's a lot of messy history
behind this, and if you don't know it all, just do what the spec says
and stop wasting everyone's time by arguing.

> 2) If you will look into the tree, in the absolute majority of cases
> REPLACING_VERSIONS is being used to determine whether informational
> messages should be shown to a user or not. Such messages usually
> include some upgrade hints or howtos; and REPLACING_VERSIONS check
> is required to avoid showing them to unaffected users. It has
> absolutely nothing to do with the error recovery done by PM itself.

Don't get into the habit of writing code that makes unnecessary
assumptions that will come back and screw users over in unexpected
situations. It's easy to do this the right way, so at this point I can
only conclude that you're persisting in trying to do it wrong just to
avoid admitting that you made a mistake from ignorance. It's OK to be
wrong sometimes (and this is why code review exists), but it's not OK
to continue to argue that you were right out of stubbornness.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Andrew Savchenko]

Hi,

On Sun, 24 Jul 2016 03:00:40 + (UTC) Duncan wrote:
> Andrew Savchenko posted on Sun, 24 Jul 2016 00:30:39 +0300 as excerpted:
> 
> > Do we ever had such case like multiple versions of the same
> > single-slotted package installed or recorded as installed in the real
> > world? I'm not sure even in this, but I may assume that it may happen
> > one day.
> > 
> > Do we have any proof that PM can recover from such situation,
> > where VDB is a mess and installed files can also be a mess? I'm not sure
> > in this at all.
> > 
> > Do we have any test suits for portage (as the most popular PM
> > implementation) for such cases? I doubt this, I can find none. I'm not
> > sure if such tests are implemented in other PM test suits too.
> 
> Think of how a package is upgraded (by portage, I don't know enough about 
> the others to describe the process for them).  The package is built, then 
> installed to a temporary location, then "qmerged" from the temporary 
> location to the live filesystem, replacing the previous version's files 
> and recording the new one in the installed-package database, then the old 
> version is unmerged and its record removed from the installed-package 
> database.
> 
> What happens if there's a crash in either the qmerge or old-version 
> unmerge steps?
> 
> Right, now there's parts of two versions in the installed-package 
> database, and who knows what files from each on the live filesystem.
> 
> I'm not a portage dev so won't comment on the test suite angle, but 
> portage has been able to handle this with the user simply redoing the 
> upgrade (whether from binpkg or full rebuild) for many years now (singe 
> before I became a gentooer in 2004, I know as I had some faulty hardware 
> at the time and regularly crashed during build and installs, which was 
> likely before REPLACING_VERSIONS was a thing), and given the number of 
> installations out there and the stress of parallel-building some packages 
> while others are installing, the code to handle this is GOING to get 
> regularly tested.

I agree with you, but REPLACING_VERSIONS has nothing to do with
such recovery.

1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
from hardware crashes forked well long before.

2) If you will look into the tree, in the absolute majority of cases
REPLACING_VERSIONS is being used to determine whether informational
messages should be shown to a user or not. Such messages usually
include some upgrade hints or howtos; and REPLACING_VERSIONS check
is required to avoid showing them to unaffected users. It has
absolutely nothing to do with the error recovery done by PM itself.

3) I also had a broken hardware (faulty memory) for a few years and
portage and other software recovered quite fine despite numerous
segfaults. So I have the experience :)

Best regards,
Andrew Savchenko


pgpUv30f2tv3O.pgp
Description: PGP signature

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

[Michał Górny]

On Sun, 24 Jul 2016 00:04:53 +0200
"Andreas K. Huettel"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Freitag, 22. Juli 2016, 15:57:36 schrieb Ciaran McCreesh:
> 
> > > > Wrong. PMS specifically requests you to account for such a
> > > > possibility.  
> > > 
> > > Common sence must prevail over formal approaches. While PMS is
> > > great, it is not perfect in all possible aspects, and this one is
> > > one of them.  
> 
> [snipping irrelevant blather]
> 
> > Slots are not the only way in which you can end up with multiple
> > installed versions of the same package. Another way is if there's a
> > fatal error during certain parts of the upgrade process.  
> 
> 1) If a package only ever had one slot, it cannot ever have two versions 
> installed at the same time. That guarantee (of only ever one slot) can be 
> given for the portage tree (sic). Obviously it doesn't work for overlays, 
> but there are many things we don't care about for overlays. [A]
> 
> 2) If a package manager leaves two versions of a non-slotted package 
> "installed" somehow, that package manager is fundamentally broken and its 
> author should forever refrain from specifying anything. It's not our job to 
> work around Paludis failure modes. [B]
> 
> 
> [A] Let's say there are overlays which package StarOffice, Go-OOO and some 
> other random OOO fork. Do I have to block them all because of file collisions 
> then?
> 
> [B] The package manager could be broken to leave some random files on the 
> system too... maybe we need some more blockers or specific error handling in 
> all ebuilds?

So, to summarize: we should dump PMS and get back to caring only what
Portage seems to do for a few developers with big mouths, because
adding a single 'for' loop is so complex you can't handle it?

Instead you prefer wasting hours of time of others to discuss ignoring
the specification rather than doing things properly. If you don't like
PMS, start the procedure for changing it. Or dump it altogether. But
stop this nonsense of 'we use this spec that was written specifically
for us but random developers can ignore random points because they
can'.

-- 
Best regards,
Michał Górny



pgp7HWsgSUbTL.pgp
Description: OpenPGP digital signature