| View previous topic :: View next topic |
| Author |
Message |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
 Posted: Sun Mar 01, 2015 11:12 pm Post subject: How's pkgcore these days? |
 |
|
I don't want to deal with Paludis's bullshit any more.
Basic usability issues getting wontfixed 30 seconds after submitting them with lazy "upstream is broken by design" excuses, never mind the fact that those words are always coming from someone whose name is on the front page of the upstream specification. Having every operation take 3 times as long as Portage, multiplied by 2 because there's no --ask switch and they refuse to add one. No sync security whatsoever and adding any requires hacking undocumented internals. They call this "a fast and flexible package manager" on their distro's homepage. What a blatant lie.
This is way past the limits of my tolerance for masochism. And that takes some doing, considering I was maintaining web apps for IE6/7 in the 2010's.
I give up, show me how nice the alternative is, with some examples maybe. I'd like to know what I'm getting into before I throw it on all my boxes.
(And I don't want to go back to Portage, if it was good enough there'd be no reason for pkgcore to exist either. And its search features kinda suck.) |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Mar 02, 2015 6:24 am Post subject: Re: How's pkgcore these days? |
|
|
| Ant P. wrote: | | And its search features kinda suck. |
One tool, one job: For searching, there's eix. |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Mon Mar 02, 2015 8:32 am Post subject: Re: How's pkgcore these days? |
|
|
| mv wrote: | | For searching, there's eix. |
Damn straight, that thing is excellent.
_________________
|
|
| Back to top |
|
|
yngwin
Retired Dev
Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China
|
| Posted: Mon Mar 02, 2015 9:09 am Post subject: Re: How's pkgcore these days? |
|
|
pkgcore is severely outdated. It can't handle EAPI=5. But recently a company was trying to hire a developer to bring it up to date. See http://archives.gentoo.org/gentoo-dev/message/48eb64957cc05f477411fd3129afd580
So if we're lucky, it will be improved.
In the meantime I suggest you use portage (with eix for search, as mentioned). Portage has improved quite a bit. For example, it has proper repo support now.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
| Back to top |
|
|
dol-sen
Retired Dev
Joined: 30 Jun 2002
Posts: 2805
Location: Richmond, BC, Canada
|
| Posted: Fri Mar 06, 2015 3:32 am Post subject: |
|
|
Actually, nearly all of EAPI 5 is working in pkgcore now. Subslot rebuilds is about the only thing not yet implemented. You will likely find some ebuilds it has trouble with, so please report them, but it is mostly working. For that you need to run the 9999 version. He hasn't released an updated version yet, but it is getting closer.
As for portage searches. It now has a new indexed search system (>=portage-2.2.17) that can automatically fall back to the old non-indexed search for the case of overlays and such being updated independently. Searches are not as fast as eix, but, they are down to about the 1 to 2 second mark.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch... |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Fri Mar 06, 2015 7:16 pm Post subject: |
|
|
2 seconds? Well I'm sold. Paludis's search (with an index file) takes on the order of several minutes. As does pretty much every other operation.
Related question:
Paludis can search for package names/versions in not-installed layman repos as if they're local. Can any of these others do that? It's really useful at times.
Unrelated question:
How would I translate stuff like MAKEOPTS="-j$(distcc -j)" to either pkgcore or portage? IIRC make.conf isn't actually parsed by bash, so that won't work. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Fri Mar 06, 2015 8:01 pm Post subject: |
|
|
I thought make.conf is sourced
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Mar 07, 2015 7:58 am Post subject: |
|
|
| Ant P. wrote: | | search for package names/versions in not-installed layman repos as if they're local. Can any of these others do that? |
There are two (I am aware of) remote eix databases hosted which contain all layman overlays and actually some more: One by gentoo and one on the zugaina server.
Eix contains scripts (eix-remote) to download these and to generate merged databases (optionally excluding installed overlays to install duplicates); these scripts can be called in a hook with eix-sync - read the eix manpage (This not done by default.)
Since eix contains two runtime switches (-R and -Z) to change the database source quickly, you can use these switches to search in the gentoo remote and/or zugaine database, respectively, if you downloaded that data. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Mar 07, 2015 8:02 am Post subject: |
|
|
| Naib wrote: | | I thought make.conf is sourced |
No, it is interpreted by python in a rather complicated way. Moreover, the interpretation of the values after sourcing is also different: For some variable names like USE, the information is accumulative, for others, like expanded IUSE variables, it is not. This is very useful and convenient, but far from being just a "source" in bash. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Mar 07, 2015 11:40 am Post subject: |
|
|
| Naib wrote: | | I thought make.conf is sourced |
| mv wrote: | | No, it is interpreted by python in a rather complicated way. Moreover, the interpretation of the values after sourcing is also different: For some variable names like USE, the information is accumulative, for others, like expanded IUSE variables, it is not. This is very useful and convenient, but far from being just a "source" in bash. |
Yes it's the python shlex module last I checked; but there's no such thing as "just" a source in bash, which actually has much more capability than shlex. (incremental stacking has been implemented in bash since the early days.) |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Sat Mar 07, 2015 3:27 pm Post subject: |
|
|
| mv wrote: | | Naib wrote: | | I thought make.conf is sourced |
No, it is interpreted by python in a rather complicated way. Moreover, the interpretation of the values after sourcing is also different: For some variable names like USE, the information is accumulative, for others, like expanded IUSE variables, it is not. This is very useful and convenient, but far from being just a "source" in bash. |
Right, so it is sh syntax but parsed into the python part of portage. I suppose that makes sense if the python part requires that information. I guess the alternative was yet another file syntax...
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Sat Mar 07, 2015 6:30 pm Post subject: |
|
|
| mv wrote: | | Naib wrote: | | I thought make.conf is sourced |
No, it is interpreted by python in a rather complicated way. Moreover, the interpretation of the values after sourcing is also different: For some variable names like USE, the information is accumulative, for others, like expanded IUSE variables, it is not. This is very useful and convenient, but far from being just a "source" in bash. |
Honestly that should just be deprecated in favor of setting in package.use. (which already works btw) |
|
| Back to top |
|
|
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Mon Mar 09, 2015 7:11 am Post subject: |
|
|
| Dr.Willy wrote: | | Honestly that should just be deprecated in favor of setting in package.use. (which already works btw) |
Why? That seems vastly less convenient.
_________________
|
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Mon Mar 09, 2015 4:53 pm Post subject: |
|
|
| arnvidr wrote: | | Why? That seems vastly less convenient. |
Sorry, what? Convenient? What is convenient about USE= ?? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Mar 09, 2015 5:12 pm Post subject: |
|
|
| Dr.Willy wrote: | | arnvidr wrote: | | Why? That seems vastly less convenient. |
Sorry, what? Convenient? What is convenient about USE= ?? |
What you are pointing out is a */* useflag in package.use has the same affect as USE=useflag in make.conf THUS, why not have useflag control done in package.use and globals can be set with */* and specifics can be set via foo/bar = ...
arnvidr is just query how is that more convenient... I see the point that all USe control would then be in one file
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Mon Mar 09, 2015 6:28 pm Post subject: |
|
|
| Naib wrote: | What you are pointing out is a */* useflag in package.use has the same affect as USE=useflag in make.conf THUS, why not have useflag control done in package.use and globals can be set with */* and specifics can be set via foo/bar = ...
arnvidr is just query how is that more convenient... I see the point that all USe control would then be in one file |
+ avoids two entirely different syntaxes for USE configuration (with cat/pkg foo syntax being required anyway)
+ single location (you can put your useflags into package.use/GLOBAL or something of course)
+ more flexible (you can do things like 'dev-java/* source' for example)
…only thing missing are these … special use flags (i forgot the name) … like X86_CPU_FLAGS or PYTHON_TARGETS. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Mon Mar 09, 2015 8:00 pm Post subject: |
|
|
| Nope, those are supported now too. The only thing that's not is using backslashes for line continuation. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Mon Mar 09, 2015 8:52 pm Post subject: |
|
|
| Ant P. wrote: | | Nope, those are supported now too. |
oh nice. Is it the same '*/* X86_CPU_FLAGS: xyz' syntax? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Mar 10, 2015 8:35 am Post subject: |
|
|
Just because it is finally (well, actually since some years...) possible to do all in one file/folder, does not mean that it is a good idea to do this.
| Dr.Willy wrote: | | + avoids two entirely different syntaxes for USE configuration (with cat/pkg foo syntax being required anyway) |
- forces the same syntax for two completely different things: Setting your preferred defaults and some intentional deviations from the defaults
- your defaults cannot easily be spread across different machines: Many people use e.g. the different make.conf locations to do this with network-mounted directories.
| Quote: | | + single location (you can put your useflags into package.use/GLOBAL or something of course) |
That's a big "-", not a "+": When you put it into package.use/GLOBAL, you are forced to treat this file special, be aware that no other file (containing e.g. */*-sources) is alphabetically before it etc.
| Quote: | | + more flexible (you can do things like 'dev-java/* source' for example) |
- far less flexible: You cannot quickly override it from the environment for testing purposes, and you would have to change your global portage configuratoin, only if you want to build a binary package for another machine which has different USE-flags.
That you can use dev-java/* in addition is fine, and completely unrelated to deprecating the extremely usefull USE.
Not to speak about the great tools like ufed which deal with your default USE: I would not want to mess such tools with random files in my /etc/portage/package.use folder which is well-structured into several files (some of them copied to different machines, others not, e.g.). |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Mar 10, 2015 9:00 am Post subject: |
|
|
What mv said.
Just because you can shove everything into one file or modus, doesn't mean you should.
OFC you can do what you want on your machine; this is still Gentoo, last I checked. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Tue Mar 10, 2015 12:13 pm Post subject: |
|
|
| mv wrote: | | - forces the same syntax for two completely different things: Setting your preferred defaults and some intentional deviations from the defaults |
yeah, setting use flags and setting use flags. two completely different things that have nothing to do with each other.
| mv wrote: | | - your defaults cannot easily be spread across different machines: Many people use e.g. the different make.conf locations to do this with network-mounted directories. |
the flexibility comes from reading files from different locations and has nothing to do with the syntax used in them
| mv wrote: | | That's a big "-", not a "+": When you put it into package.use/GLOBAL, you are forced to treat this file special, be aware that no other file (containing e.g. */*-sources) is alphabetically before it etc. |
*/* entries can be wherever you want them to be.
| mv wrote: | | - far less flexible: You cannot quickly override it from the environment for testing purposes, and you would have to change your global portage configuratoin, only if you want to build a binary package for another machine which has different USE-flags. |
Are we still talking about config files? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Tue Mar 10, 2015 12:34 pm Post subject: |
|
|
Look its two ways todo a similar thing... both have user experience preference over the other BUT that doesn't negate both are valid methods.
Take /etc/portage/package.use (and the others) can ACTUALLY be directories. Paludis and co for ages tried to push via the PMS that that is wrong and should only be files (probably because they couldn;t support it). Now having all those as directories is useful because I can apply specific package use in groups:
All the py27 ONLY applications captured in one file rather than interleaved in a package.use file.
| Code: | cat /etc/portage/package.use/py27
media-gfx/inkscape python_targets_python2_7 python_single_target_python2_7
net-analyzer/ntop python_targets_python2_7 python_single_target_python2_7
media-gfx/gimp python_targets_python2_7 python_single_target_python2_7
app-i18n/ibus python_targets_python2_7 python_single_target_python2_7
dev-vcs/git python_targets_python2_7 python_single_target_python2_7
dev-util/glade python_targets_python2_7 python_single_target_python2_7
media-libs/alsa-lib python_targets_python2_7 python_single_target_python2_7
net-print/cups python_targets_python2_7 python_single_target_python2_7
net-print/hplip python_targets_python2_7 python_single_target_python2_7
gnome-extra/cinnamon python_targets_python2_7 python_single_target_python2_7
dev-libs/gobject-introspection python_targets_python2_7 python_single_target_python2_7
dev-util/itstool python_targets_python2_7 python_single_target_python2_7
sys-libs/talloc python_targets_python2_7 python_single_target_python2_7
sys-libs/tdb python_targets_python2_7 python_single_target_python2_7
dev-java/antlr python_targets_python2_7 python_single_target_python2_7
net-analyzer/net-snmp python_targets_python2_7 python_single_target_python2_7
sys-libs/tevent python_targets_python2_7 python_single_target_python2_7
app-text/asciidoc python_targets_python2_7 python_single_target_python2_7
app-admin/system-config-printer-gnome python_targets_python2_7 python_single_target_python2_7
app-admin/system-config-printer-common python_targets_python2_7 python_single_target_python2_7
dev-util/gtk-doc python_targets_python2_7 python_single_target_python2_7
dev-libs/libdbusmenu python_targets_python2_7 python_single_target_python2_7
app-emulation/playonlinux python_targets_python2_7 python_single_target_python2_7 |
Oh I am sure people would and probably will denounce this as bad but it works and it works for me AND others might find it useful,
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Tue Mar 10, 2015 1:29 pm Post subject: |
|
|
| Naib wrote: | | Look its two ways todo a similar thing... |
Common man, that's not how online discussions work. You have to quote lots of single lines from a post and prove them wrong 1-by-1. I thought you'd been in OTW long enough. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Tue Mar 10, 2015 1:32 pm Post subject: |
|
|
| Dr.Willy wrote: | | Naib wrote: | | Look its two ways todo a similar thing... |
Common man, that's not how online discussions work. You have to quote lots of single lines from a post and prove them wrong 1-by-1. I thought you'd been in OTW long enough. |
blinkers are for horses. System people look at the complete picture
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Mar 10, 2015 4:59 pm Post subject: |
|
|
| Quote: | [quote="Dr.Willy"] | mv wrote: | | - forces the same syntax for two completely different things: Setting your preferred defaults and some intentional deviations from the defaults |
yeah, setting use flags and setting use flags |
You are not able to read. Or you do not understand the meaning of "default".
| Quote: | | the flexibility comes from reading files from different locations and has nothing to do with the syntax used in them |
It has to do with the different purpose of the files: One for setting defaults, and others for overriding.
| Quote: | | */* entries can be wherever you want them to be. |
I couldn't believe that portage is so unsane, but actually it is. That's an argument of not using any wildcard in /etc/portage/packge* at all: The result is rather random and cannot be controled by the order: If you have | Quote: | */*fox -system-icu
www-client/* system-icu |
who should win for www-cllient/firefox? By portage's algorithm the result appears to be independent of the order of these two lines which makes no sense at all: The only sensible thing would be that later entries override earlier ones.
| Quote: | | mv wrote: | | - far less flexible: You cannot quickly override it from the environment for testing purposes, and you would have to change your global portage configuratoin, only if you want to build a binary package for another machine which has different USE-flags. |
Are we still talking about config files? |
We are talking about your unfortunate suggestion to deprecate a very useful portage configuration variable, only because there exists a clumsy method to obtain a similar outcome in another way.
As SteveL has written: You are free to do it as you want, and if you think that having all in one file and not using ufed is good for you - great, do it!
But do not force others to change their way how they would like to configure their system! |
|
| Back to top |
|
|
|
Gentoo Chat
