Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 417693 - Change ordering of packages that satisfy virtual/pkgconfig
Summary: Change ordering of packages that satisfy virtual/pkgconfig
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All All
: Normal enhancement (vote)
Assignee: Freedesktop bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 417551
  Show dependency tree
 
Reported: 2012-05-26 20:50 UTC by Richard Yao
Modified: 2012-05-28 00:07 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Yao gentoo-dev 2012-05-26 20:50:24 UTC
I would like to change the ordering of the packages that satisfy virtual/pkgconfig to be the following:

dev-util/pkgconf[pkg-config]
dev-util/pkgconfig-openbsd[pkg-config]
dev-util/pkgconfig
dev-util/pkg-config-lite

This will permit the default pkgconfig implementation to be overridden on a per profile basis. Are there any objections to this?

This change should be harmless, so I would like to commit it within 72 hours.
Comment 1 Mike Gilbert gentoo-dev 2012-05-27 05:57:41 UTC
(In reply to comment #0)
> This will permit the default pkgconfig implementation to be overridden on a
> per profile basis.

How so? I don't see how the order would affect this in any way.
Comment 2 Alexandre Rostovtsev (RETIRED) gentoo-dev 2012-05-27 09:09:00 UTC
(In reply to comment #0)
> Are there any objections to this?

Yes. IMHO the default pkgconfig implementation, i.e. the one that goes first in the virtual list, should be dev-util/pkgconfig. It is the canonical implementation, and the one that that is used in their testing by 99.9% of upstream developers whose work we package.

A new Gentoo user who runs "emerge virtual/pkgconfig" should get dev-util/pkgconfig by default. Users who are building for embedded systems or have specific requirements are certainly free to manually select one of the other implementations, just like they are free to manually select e.g. net-misc/dropbear instead of net-misc/openssh.

If there is an entire profile that needs a specific non-canonical pgconfig implementation, then the proper solution is to add a USE flag to virtual/pkgconfig that changes the ordering of implementations, and enable that USE flag for the profile.
Comment 3 Pacho Ramos gentoo-dev 2012-05-27 10:06:43 UTC
I fully agree with Alexandre, also, USE flag solution would work for both group of users (people having no problem on getting glib pulled in and embedded users)
Comment 4 Richard Yao gentoo-dev 2012-05-27 11:54:38 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > This will permit the default pkgconfig implementation to be overridden on a
> > per profile basis.
> 
> How so? I don't see how the order would affect this in any way.

If we set dev-util/pkgconf[pkg-config] in Gentoo FreeBSD (or dev-util/pkgconfig-openbsd[pkg-config] in Gentoo OpenBSD), emerge will have no reason to change existing installs.

(In reply to comment #2)
> (In reply to comment #0)
> > Are there any objections to this?
> 
> Yes. IMHO the default pkgconfig implementation, i.e. the one that goes first
> in the virtual list, should be dev-util/pkgconfig. It is the canonical
> implementation, and the one that that is used in their testing by 99.9% of
> upstream developers whose work we package.
> 
> A new Gentoo user who runs "emerge virtual/pkgconfig" should get
> dev-util/pkgconfig by default. Users who are building for embedded systems
> or have specific requirements are certainly free to manually select one of
> the other implementations, just like they are free to manually select e.g.
> net-misc/dropbear instead of net-misc/openssh.
> 
> If there is an entire profile that needs a specific non-canonical pgconfig
> implementation, then the proper solution is to add a USE flag to
> virtual/pkgconfig that changes the ordering of implementations, and enable
> that USE flag for the profile.

If this change is made, a new Gentoo user who runs "emerge virtual/pkgconfig" will still dev-util/pkgconfig by default. Portage will not select dev-util/pkgconf or dev-util/pkgconfig-openbsd unless it has the pkg-config USE flag toggled, so nothing changes there.
Comment 5 Samuli Suominen gentoo-dev 2012-05-27 12:05:13 UTC
While I can understand the reasoning I don't agree with the method, so +1 for Comment #2. 
It should be done with prefixing USE flags, like 
elibc_uclibc? ( dev-util/pkgconf[pkg-config] )
Comment 6 Richard Yao gentoo-dev 2012-05-27 12:06:17 UTC
(In reply to comment #5)
> While I can understand the reasoning I don't agree with the method, so +1
> for Comment #2. 
> It should be done with prefixing USE flags, like 
> elibc_uclibc? ( dev-util/pkgconf[pkg-config] )

This change has nothing to do with embedded systems. See bug #417551, which depends on this.
Comment 7 Samuli Suominen gentoo-dev 2012-05-27 12:12:59 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > While I can understand the reasoning I don't agree with the method, so +1
> > for Comment #2. 
> > It should be done with prefixing USE flags, like 
> > elibc_uclibc? ( dev-util/pkgconf[pkg-config] )
> 
> This change has nothing to do with embedded systems. See bug #417551, which
> depends on this.

Bug 417551 is trying to accomplish something that is not worth accomplishing, nor changes my opinion on the wrong method as userland_BSD? ( ) could be used then.
Comment 8 Richard Yao gentoo-dev 2012-05-27 12:27:34 UTC
(In reply to comment #7)
> Bug 417551 is trying to accomplish something that is not worth
> accomplishing, nor changes my opinion on the wrong method as userland_BSD? (
> ) could be used then.

The USE flag being set means that implementation is preferred over dev-util/pkgconfig.

With that said, would anyone have an issue with:

!elibc_glibc? ( dev-util/pkgconf[pkg-config]
dev-util/pkgconfig-openbsd[pkg-config] )
dev-util/pkgconfig
dev-util/pkg-config-lite
elibc_glibc? ( dev-util/pkgconf[pkg-config]
dev-util/pkgconfig-openbsd[pkg-config] )

That should cover both embedded systems and BSD, while leaving things untouched on glibc systems.
Comment 9 Richard Yao gentoo-dev 2012-05-27 12:33:43 UTC
(In reply to comment #8)
> That should cover both embedded systems and BSD, while leaving things
> untouched on glibc systems.

Just as a side note, I can see how dev-util/pkgconf would be useful for embedded systems. Since people mentioned them, we might as well address both issues at once.
Comment 10 Samuli Suominen gentoo-dev 2012-05-27 16:00:46 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > Bug 417551 is trying to accomplish something that is not worth
> > accomplishing, nor changes my opinion on the wrong method as userland_BSD? (
> > ) could be used then.
> 
> The USE flag being set means that implementation is preferred over
> dev-util/pkgconfig.
> 
> With that said, would anyone have an issue with:
> 
> !elibc_glibc? ( dev-util/pkgconf[pkg-config]
> dev-util/pkgconfig-openbsd[pkg-config] )
> dev-util/pkgconfig
> dev-util/pkg-config-lite
> elibc_glibc? ( dev-util/pkgconf[pkg-config]
> dev-util/pkgconfig-openbsd[pkg-config] )

-1, quite a greedy assumption glib-2 would be buildable only on glibc systems
Comment 11 Samuli Suominen gentoo-dev 2012-05-27 16:08:41 UTC
(In reply to comment #10)
> > With that said, would anyone have an issue with:
> > !elibc_glibc? ( dev-util/pkgconf[pkg-config]
> > dev-util/pkgconfig-openbsd[pkg-config] )
> > dev-util/pkgconfig
> > dev-util/pkg-config-lite
> > elibc_glibc? ( dev-util/pkgconf[pkg-config]
> > dev-util/pkgconfig-openbsd[pkg-config] )
> 
> -1, quite a greedy assumption glib-2 would be buildable only on glibc systems

plus it has the ! logic reversed, plus it's still changing the order unnecessarily... sorry to say but that's just entirely wrong.
Comment 12 Richard Yao gentoo-dev 2012-05-27 16:10:51 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Bug 417551 is trying to accomplish something that is not worth
> > > accomplishing, nor changes my opinion on the wrong method as userland_BSD? (
> > > ) could be used then.
> > 
> > The USE flag being set means that implementation is preferred over
> > dev-util/pkgconfig.
> > 
> > With that said, would anyone have an issue with:
> > 
> > !elibc_glibc? ( dev-util/pkgconf[pkg-config]
> > dev-util/pkgconfig-openbsd[pkg-config] )
> > dev-util/pkgconfig
> > dev-util/pkg-config-lite
> > elibc_glibc? ( dev-util/pkgconf[pkg-config]
> > dev-util/pkgconfig-openbsd[pkg-config] )
> 
> -1, quite a greedy assumption glib-2 would be buildable only on glibc systems

I fail to see how anything changes on glibc systems. The ebuild has the USE flag off by default. It would be optionally set on in a profile's package.use or the local system's package.use. Would you please explain how this is "buildable only on glibc systems"?
Comment 13 Richard Yao gentoo-dev 2012-05-27 16:12:39 UTC
(In reply to comment #12)
> I fail to see how anything changes on glibc systems. The ebuild has the USE
> flag off by default. It would be optionally set on in a profile's
> package.use or the local system's package.use. Would you please explain how
> this is "buildable only on glibc systems"?

To be more clear, I fail to see how any of this changes anything on any systems unless package.use in either the profile or local system is modified, at which point, dev-util/pkgconfig has no business being on the system.
Comment 14 Richard Yao gentoo-dev 2012-05-27 17:09:25 UTC
Are there any objections to this:

userland_BSD? ( dev-util/pkgconf[pkg-config]
dev-util/pkgconfig-openbsd[pkg-config] )
dev-util/pkgconfig
dev-util/pkg-config-lite
!userland_BSD? ( dev-util/pkgconf[pkg-config]
dev-util/pkgconfig-openbsd[pkg-config] )
Comment 15 Richard Yao gentoo-dev 2012-05-27 17:25:54 UTC
I was told that what I suggested in comment #14 was difficult to read, so here is a revision:

userland_BSD? (
	|| (
		dev-util/pkgconf[pkg-config]
		dev-util/pkgconfig-openbsd[pkg-config]
		dev-util/pkgconfig
		dev-util/pkg-config-lite
	)
)
!userland_BSD? (
	|| (
		dev-util/pkgconfig
		dev-util/pkg-config-lite
		dev-util/pkgconf[pkg-config]
		dev-util/pkgconfig-openbsd[pkg-config]
	)
)

It is semantically equivalent, but easier to read. This change can only affect Gentoo/*BSD.
Comment 16 Richard Yao gentoo-dev 2012-05-27 17:50:29 UTC
I discussed this change with ssuominen in IRC. I will take responsibility for fixing any bugs introduced in Gentoo/*BSD as the direct result of changing this virtual package. If the BSD team changes its mind, this change will be reverted.

Change committed to CVS.
Comment 17 Richard Yao gentoo-dev 2012-05-27 18:30:47 UTC
This change was reverted because a quirk in portage caused `env USE=pkg-config emerge -1v virtual/pkgconfig` to prefer pkgconf. Apparently, dependencies with USE flags come last. It is a consequence of the resolution of bug #278729.
Comment 18 Alexis Ballier gentoo-dev 2012-05-27 19:45:24 UTC
can anyone explain why the initial proposal was bad ?

dev-util/pkgconf[pkg-config]
dev-util/pkgconfig-openbsd[pkg-config]
dev-util/pkgconfig
dev-util/pkg-config-lite


-> with USE=-pkg-config, dev-util/pkgconfig is prefered
-> with USE=pkg-config, dev-util/pkgconf[pkg-config] is prefered

this is the whole point of the proposal: let profiles easily set the default implementation for a virtual


shall we get back to old style virtuals ? :)

other solution would be to mask dev-util/pkgconfig on profiles where we want pkgconf to be the default, but this seems poor man's solution to ask people who really want to use dev-util/pkgconfig to unmask it...
Comment 19 Mike Gilbert gentoo-dev 2012-05-27 19:50:28 UTC
(In reply to comment #18)
> can anyone explain why the initial proposal was bad ?

I just think it is confusing to rely on a quirk in the way portage resolves dependencies like that, as demonstrated by my question in comment 1.
Comment 20 Richard Yao gentoo-dev 2012-05-27 20:00:46 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > can anyone explain why the initial proposal was bad ?
> 
> I just think it is confusing to rely on a quirk in the way portage resolves
> dependencies like that, as demonstrated by my question in comment 1.

Looking at the package manager specification, I would say that the notion of having the first match satisfy an any-of group an order is a quirk as well. It might be worthwhile to define this behavior in the PMS.
Comment 21 Richard Yao gentoo-dev 2012-05-27 20:08:13 UTC
(In reply to comment #18)
> can anyone explain why the initial proposal was bad ?

Thinking about this some more, the package manager specification dictates that if a package is installed that satisfies the any-of group, then that package will be retained. So even if the order changes, we won't be able to migrate existing installs to pkgconf by setting the USE flag. Doing that would require either dropping keywords on pkgconfig or masking pkgconfig.

Consequently, since the only benefit of the new order would have been in the stage3 had portage not had a quirk that prevented it from obeying the order in the any-of group, we could probably do some magic in catalyst to force use of pkgconf.
Comment 22 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2012-05-27 23:37:00 UTC
(In reply to comment #21)
> 
> Consequently, since the only benefit of the new order would have been in the
> stage3 had portage not had a quirk that prevented it from obeying the order
> in the any-of group, we could probably do some magic in catalyst to force
> use of pkgconf.

There's no need nor is it desired to do any "magic" on catalyst. You can just take advantage of portdir_overlay for the desired targets to mask pkgconfig and enable pkgconfig use flag for pkgconf and have portage install pkgconf.
Comment 23 Alexis Ballier gentoo-dev 2012-05-27 23:48:04 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > can anyone explain why the initial proposal was bad ?
> 
> I just think it is confusing to rely on a quirk in the way portage resolves
> dependencies like that, as demonstrated by my question in comment 1.

Again, I dont understand. Where is the quirk in: || ( a b c ) will select the leftmost installable one. ?¿? This is fairly well-known behavior.

 Since pkgconf[pkg-config] isnt enabled by default, this doesnt change the preference, and the default remains pkgconfig, while letting profiles that need it set another default.

PS: I was only half kidding with resurecting old style virtuals, they allowed this...
Comment 24 Mike Gilbert gentoo-dev 2012-05-28 00:07:01 UTC
(In reply to comment #23)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > can anyone explain why the initial proposal was bad ?
> > 
> > I just think it is confusing to rely on a quirk in the way portage resolves
> > dependencies like that, as demonstrated by my question in comment 1.
> 
> Again, I dont understand. Where is the quirk in: || ( a b c ) will select
> the leftmost installable one. ?¿? This is fairly well-known behavior.

Never mind; maybe the quirk is just in my head.