| View previous topic :: View next topic |
| Author |
Message |
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
 Posted: Tue Mar 10, 2015 9:47 pm Post subject: |
 |
|
| mv wrote: | You are not able to read. Or you do not understand the meaning of "default".
[…]
It has to do with the different purpose of the files: One for setting defaults, and others for overriding. |
Or how about this then: The profile sets the defaults and USE overrides the defaults. Now what?
| mv wrote: | | I couldn't believe that portage is so unsane |
Well now you can. That's a plus I guess.
| mv wrote: | | 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. |
The more specific one? |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Mar 11, 2015 3:42 am Post subject: |
|
|
| mv wrote: | | It has to do with the different purpose of the files: One for setting defaults, and others for overriding. |
| Dr.Willy wrote: | | Or how about this then: The profile sets the defaults and USE overrides the defaults. Now what? |
Now stop being disingenuous and cut out the pretence that you don't understand the difference between "distro-default" (actually "profile default" as this is Gentoo), "site-default" and "package-specific override."
This is a pointless discussion: all we're exploring is how you only see things one way, so think that's the only way which should be implemented.
The reasons why we disagree with you are pretty clear. As mv pointed out:
| Quote: | | 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. |
Either show he's wrong, and that your method isn't simply a complexified way of performing an existing simple operation, or let's move on. |
|
| Back to top |
|
|
Dr.Willy
Guru
Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany
|
| Posted: Wed Mar 11, 2015 12:35 pm Post subject: |
|
|
| steveL wrote: | | Now stop being disingenuous and cut out the pretence that you don't understand the difference between "distro-default" (actually "profile default" as this is Gentoo), "site-default" and "package-specific override." |
I understand what you are saying I just think your definitions of "default" and "override" are entirely made up.
You have
*/* foo
cat/* foo
cat/pkg foo
=cat/pkg-1.2.3 foo
and you guys ramble on how one is setting defaults and then the other is overriding defaults and that those are entirely different things that have nothing to do with each other.
You set a use flag for all packages, for some packages, for one package, for one version of a package.
| steveL wrote: | | Either show he's wrong, and that your method isn't simply a complexified way of performing an existing simple operation, or let's move on. |
Dude, what … ?
First of all I say USE= should be deprecated because it's redundand for specifying use flags, mv argues that it has uses (heh) that '*/* foo' cant satisfy and should thus be kept. Good luck finding the guy who's wrong.
Next the current situation is that both alternatives already exist. It's not 'my' method it's one that was created because it was required and couldn't be done with USE= at all. A 'complexified way of performing an existing simple operation' what are you even talking about?! |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Wed Mar 11, 2015 12:54 pm Post subject: |
|
|
| Dr.Willy wrote: | | steveL wrote: | | Now stop being disingenuous and cut out the pretence that you don't understand the difference between "distro-default" (actually "profile default" as this is Gentoo), "site-default" and "package-specific override." |
I understand what you are saying I just think your definitions of "default" and "override" are entirely made up.
You have
*/* foo
cat/* foo
cat/pkg foo
=cat/pkg-1.2.3 foo
and you guys ramble on how one is setting defaults and then the other is overriding defaults and that those are entirely different things that have nothing to do with each other.
You set a use flag for all packages, for some packages, for one package, for one version of a package.
| steveL wrote: | | Either show he's wrong, and that your method isn't simply a complexified way of performing an existing simple operation, or let's move on. |
Dude, what … ?
First of all I say USE= should be deprecated because it's redundand for specifying use flags, mv argues that it has uses (heh) that '*/* foo' cant satisfy and should thus be kept. Good luck finding the guy who's wrong.
Next the current situation is that both alternatives already exist. It's not 'my' method it's one that was created because it was required and couldn't be done with USE= at all. A 'complexified way of performing an existing simple operation' what are you even talking about?! |
Query (as I havn't tried)
make.conf:
USE = " ... foo ..."
emerge some/package-1 will then have USE=foo
make.conf:
USE = " ... foo ..."
package.use:
*/* = "... foo"
emerge cat/pkg-1 will then have USE=foo
make.conf:
USE = " ... foo ..."
package.use:
*/* = "... foo"
cat/pkg -foo
emerge cat/pkg-1 will then have USE= -foo
make.conf:
USE = " ... foo ..."
package.use:
some/package -foo
*/* = "... foo"
emerge cat/pkg-1 will then have USE= foo
correct?
ie while make.conf is "parsed" 1st, package.use overrides any additional user choice and THUS the order in which you do
*/* foo
cat/* foo
cat/pkg foo
=cat/pkg-1.2.3 foo
with regards to all combinations of cat/pkg becomes key - SOMETHING that is the case right now anyway
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Mar 11, 2015 4:05 pm Post subject: |
|
|
| Dr.Willy wrote: | | I understand what you are saying I just think your definitions of "default" and "override" are entirely made up. |
And I think you're falling into the trap of equating "implementation" with "concept", which I label a "trap" as it is a common mistake.
It always comes up when someone sees that a complexified approach "does the same thing" as a simple one, so "let's just munge the two into one thing (clever, no?)" No, it's not clever, it's just nub. Now you have two complex cases, both of which are fragile and coupled to something else they didn't have to be; instead of one well-known, simple and robust approach, and a more complex one for the more complex cases, both of which feed off each other, in terms of being able to test one against the other.
Similar dodgy reasoning applies to the whole "we don't need no split /usr, we must all use an initrd, because Lennart sez so" idiocy.
Fundamentally it comes down to a lack of appreciation for the bigger picture, which is about notation before it is about anything. Diverse methods lead to a better outcome for an ecosystem.
You see the same issue in portage space, where we cannot discuss library dependencies unless we do so in a convoluted manner, and the impl has to infer their existence instead of simply being told about them directly, a notation which opens the door to so much more, but we can't even discuss things in simple terms. Instead the impl must build the same set that we want to reason about, in a way that is not conducive to further reasoning across the board, since it is hidden. Previously-sane coders witter on about the same set using different terms at different points; since they can see it in their head, it doesn't need to be dealt with directly, or something.
Monocultural "only what I see in front of me is what matters" approaches have a name; One True Way.
Really that should be EOD whenever it's pointed out, but it never is.. Plus ca change ;)
They lead to vendor lock-in, and crippled systems that are only really good for foisting onto the marks so you can extract a revenue stream from them. Problem is, people just aren't that stupid, all of the time. Still, one can make a good living from the ones you can fool all of the time, and the rest can be browbeaten, apparently.
Hopefully that's explained what I meant enough for you to understand my point.
I don't expect you to agree, but then this whole thing is a sidetrack from the original thread, so I don't much care either; mainly because "what are you even talking about?" |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Mar 11, 2015 8:47 pm Post subject: |
|
|
| Dr.Willy wrote: | | Well now you can. That's a plus I guess. |
A plus in convincing me that one should avoid the inconsistent behaviour of portage concerning wildcards as far as possiible: Now I am sure that I will never use */* in package.use, even if it would not lack the other possibilities I had described and you kept ignoring.
In fact, you have not given any sane alternative to the valuable uses of USE which I have given.
And even if some uses could be emulated in an inconvient way (e.g. by exporting new directories with nfs, symlinking, and other stuff, causing troubles for backups etc): Why do you want to force all system administrators to follow your point of view?
Only that you can say: "But now the configuration possibilities are orthogonal"
As if orthogonality was any desirable goal.
If you insist on orthogonality, I have a better suggestion: Deprecate */* from package.use since this is already covered by USE.
Of course, I do not make this suggestion seriously, because I am not so narrow minded as you and see that it is very useful if things can be configured in different ways. You do not seem to understand that gentoo is about choice.
| Quote: | | The more specific one? |
And again you show that you cannot read or intentionally keep ignoring what I have written. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Mar 22, 2015 7:06 am Post subject: |
|
|
This information does not really match to the topic but to the previous discussion: This is how portage sets the priority for /etc/portage/package.*:
| Code: | =cpv 6
~cpv 5
=cpv* 4
cp:slot 3
>cpv 2
<cpv 2
>=cpv 2
<=cpv 2
cp 1
cp:slot with extended syntax 0
cp with extended syntax -1 |
where (only according to my testing, so I might be false) "extended syntax" means that some willd cards are used, and moreover, the "extended syntax" expressions are simply sorted alphabetically. So, in a sense, it is pure accident that "*/*" is ordered before "*/*-sources"
eix-0.30.8 will "almost" support the same order with one exception: The distinction between "cp" and "cp:slot" for packages with extended syntax is only made if the "cp" part is identical. Thus, for example, eix-0.30.8 uses the order "*/* */*::foo */*-sources */*-sources::foo" while portage uses "*/* */sources */*::foo */*-sources::foo". Fixing this would involve changing the lookup algorithm in eix completely. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Tue Apr 07, 2015 11:42 pm Post subject: |
|
|
Okay it's a month late but I finally got around to doing what I said I'd do. Short version for anyone else who's looking to dump Paludis, caveat emptor applies:
| Code: | #!/bin/sh
set -e
cave resolve -x eix gentoolkit
move() { mv -v /etc/paludis/"$1".conf.d/ /etc/portage/package."$2"/; }
# Earlier comment about portage not recognising backslash line continuations in package.* still applies.
move use use
move package_mask mask
move package_unmask unmask
move keywords accept_keywords
move licenses license
# Paludis uses *, Portage uses **
sed -i -e 's/\s\*/ **/' /etc/portage/package.accept_keywords/*
# Paludis puts some weird prefix on lines in these, and I've never seen a point to it.
# Take care with nested sets because Portage wants the @-prefix on them.
mkdir -p /etc/portage/sets
for set in /etc/paludis/sets/*.conf; do
awk '{print $2}' $set > /etc/portage/sets/$(basename $set)
done
# Paludis dumps packages and sets into the same file
sed -n '/\//p' < /var/db/pkg/world >| /var/lib/portage/world
sed -n '/\//d; s/^/@/p' < /var/db/pkg/world >| /var/lib/portage/world_sets
# Portage is still mildly brain-damaged so we need to "fix" vdb for it so it shows correct origin repos instead of __unknown__
find /var/db/pkg -name REPOSITORY -exec rename REPOSITORY repository \{} +
# Clean up cache/build dirs
rm -rf /var/tmp/paludis /var/cache/paludis |
There's still no nice equivalent of Paludis' repositories system 6 years on; repos.conf's 3-4 lines per overlay is an ugly mountain of boilerplate in comparison (and broken to boot). Hopefully they'll improve it before it escapes ~arch.
Porting /etc/paludis/bashrc to /etc/portage/{bashrc,make.conf} is a manual affair (but a fairly easy one). My make.conf only contains CFLAGS, CXXFLAGS=$CFLAGS, CHOST, LDFLAGS, DISTDIR, GENTOO_MIRRORS, FEATURES and PORTAGE_GPG_DIR; everything else is already neatly organised in those directories.
And finally, some numbers from my netbook (~50-60 things to update):
| Code: | # \time -v cave resolve -c world
Command being timed: "cave resolve -c world"
User time (seconds): 190.03
System time (seconds): 8.11
Percent of CPU this job got: 98%
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:21.49
Maximum resident set size (kbytes): 95716
Major (requiring I/O) page faults: 8
Minor (reclaiming a frame) page faults: 910436
Voluntary context switches: 8856
Involuntary context switches: 26529
Swaps: 0
File system inputs: 1072
File system outputs: 10328
Exit status: 0
# \time -v emerge -DpvuN --with-bdeps=y @world
Command being timed: "emerge -DpvuN --with-bdeps=y @world"
User time (seconds): 165.74
System time (seconds): 1.96
Percent of CPU this job got: 98%
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:50.04
Maximum resident set size (kbytes): 91300
Major (requiring I/O) page faults: 2
Minor (reclaiming a frame) page faults: 28853
Voluntary context switches: 481
Involuntary context switches: 26867
Swaps: 0
File system inputs: 18736
File system outputs: 5432
Exit status: 0 |
May not seem like a big difference, but it's huge when you don't have an --ask option. I don't even have the patience to time a `cave search` command right now, suffice to say it'd take upwards of an hour to rebuild the index on that CPU. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Apr 15, 2015 3:31 am Post subject: |
|
|
I've got most of the kinks worked out now, still stuck on two things though:
What's the old-world equivalent of `cave resolve world --reinstall-scm weekly`? Portage seems to not update any of my installed -9999 packages on its own and I don't see anything obvious in the manpages.
`eix -lv` is totally unreadable compared to `cave show`. Is there a config option or way to make it pretty-print stuff like use deps? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Apr 15, 2015 1:09 pm Post subject: |
|
|
| Ant P. wrote: | | `eix -lv` is totally unreadable compared to `cave show`. Is there a config option or way to make it pretty-print stuff like use deps? |
You can make it print only the dependency string of a particular version or only a particular dependency string (DEPEND, RDEPEND, PDEPEND).
But apart from this: no. eix treats the dependency strings just as strings |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Apr 16, 2015 1:31 am Post subject: |
|
|
| Ant P. wrote: | | What's the old-world equivalent of `cave resolve world --reinstall-scm weekly`? Portage seems to not update any of my installed -9999 packages on its own and I don't see anything obvious in the manpages. |
| Code: | | emerge -av @live-rebuild |
You can add it to world in cli, along with whatever else.
cf: emerge --list-sets
Note that if you have a package which is in world, that comes from a 9999 ebuild, eg in your local overlay or unmasked, then that's the version portage will try to upgrade as part of @world, in any case. (Standard unversioned package in world will do that.) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
