[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

On 27/07/14 22:01, Markus Meier (maekke) wrote: > maekke 14/07/27 19:01:15 > > Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild > x265-0.8.ebuild > Log: > add ~arm, bug #510340 Package bumping is done by, eg.: # cp x265-.ebuild x265-1.3.ebuil

Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a

On 27/07/14 14:33, Pacho Ramos wrote: > # Pacho Ramos (27 Jul 2014) > # Not buildable for a long time, bug #414903 > # Removal in a month. > media-plugins/vdr-dxr3 > media-video/dxr3config > media-video/em8300-libraries You forgot to mask em8300-modules. That's the package that's actually broken

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 27/07/14 16:47, Michał Górny wrote: > Dnia 2014-07-27, o godz. 14:42:24 > Samuli Suominen napisał(a): > >> On 26/07/14 15:49, Ciaran McCreesh wrote: >>> On Sat, 26 Jul 2014 12:41:16 + (UTC) >>> Martin Vaeth wrote: hasufell wrote: > Dynamics deps are already broken, not consisten

[gentoo-dev] Re: Avoiding rebuilds

hasufell wrote: > Ulrich Mueller: >> >> I wonder if it wouldn't be saner to leave our revision syntax >> untouched. As already mentioned, -r1.1 is only one of several possible ways how to achieve the same aim; I am not speaking in favour for a particular method. The -r1.1 method has the advantage

[gentoo-dev] Re: don't rely on dynamic deps

Rich Freeman wrote: > > I'd think that a change in repository should probably be treated like > a revbump. I agree. At least, currently eix already shows [U] in such a situation, and IMHO it would be wise if portage would suggest to upgrade/downgrade then, too. But this is a topic which is rather

[gentoo-dev] Re: don't rely on dynamic deps

Michał Górny wrote: > > Consider the following: > > 1. A depends on B, both are installed, > > 2. dependency on B is removed, emerge --depclean uninstalls B thanks > to dynamic-deps, > > 3. B is treecleaned (nothing depends on it), > > 4. old version of A is removed (user doesn't update it yet), t

[gentoo-dev] Re: don't rely on dynamic deps

Kent Fredric wrote: > 1. User installs Foo > 2. Gentoo needs to change what Foo depends on > 3. Gentoo simply tweaks the ebuild and doesn't bump [A] > 4. User syncs. > 5. Subsequent emerges see dependencies from [A] which are fixed and works >in the interim > 6. A gets removed. > 7. User syncs

Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a

On 27/07/14 08:32 PM, James Cloos wrote: >> "PR" == Pacho Ramos writes: > > PR> # Pacho Ramos (27 Jul 2014) > PR> # Doesn't build on non-selinux setups (#498032) > PR> # Removal in a month. > PR> dev-lang/gforth > > Did you even try 0.7.3 before coming to that conclusion? > > It needs a bu

Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a

> "PR" == Pacho Ramos writes: PR> # Pacho Ramos (27 Jul 2014) PR> # Doesn't build on non-selinux setups (#498032) PR> # Removal in a month. PR> dev-lang/gforth Did you even try 0.7.3 before coming to that conclusion? It needs a bump, not a dump. And for a GNU package at that. -JimC -- J

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-27 23h59 UTC

The attached list notes all of the packages that were added or removed from the tree, for the week ending 2014-07-27 23h59 UTC. Removals: virtual/perl-PodParser 2014-07-21 19:12:16 dilfridge perl-core/digest-base 2014-07-22 19:34:16 dilfridge virtual/perl

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-27 23:33 Ciaran McCreesh napisał(a): > On Sun, 27 Jul 2014 17:26:27 -0400 > Rich Freeman wrote: > > But, in that case you can put the necessary ebuilds into your overlay > > and then portage can make everything right. > > Oh? Please explain to us a) how the overlay interaction *actually*

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 28 July 2014 09:46, Rich Freeman wrote: > Then portage could look for any change in state and that would trigger > a build-less re-merge, which would update vdb with the new state > (including the new hash). > If we're scared about this being worse than what we have, I notice there's a bunch

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:50 PM, Kent Fredric wrote: > > On 28 July 2014 09:34, Rich Freeman wrote: >> >> and if it doesn't work for them, >> they'll sync in the updates one way or another (using an overlay if >> necessary). > > > However, in the case the package gets removed from tree, an update

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 09:34, Rich Freeman wrote: > and if it doesn't work for them, > they'll sync in the updates one way or another (using an overlay if > necessary). > However, in the case the package gets removed from tree, an updates based approach would allow the dependencies to be cleaned up lon

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sun, Jul 27, 2014 at 8:04 AM, Rich Freeman wrote: > > Doing this would require having portage cache a hash of whatever > ebuild it last parsed, and perhaps its eclasses as well if we permit > revbump-less eclass changes. Then it would have to check for when > these change, perhaps this might b

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:33 PM, Ciaran McCreesh wrote: > On Sun, 27 Jul 2014 17:26:27 -0400 > Rich Freeman wrote: >> But, in that case you can put the necessary ebuilds into your overlay >> and then portage can make everything right. > > Oh? Please explain to us a) how the overlay interaction *a

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:27 PM, Kent Fredric wrote: > > On 28 July 2014 08:56, Ciaran McCreesh > wrote: >> >> > To me it seems like a simple data model bug that vdb does not get >> > updated to reflect the new situation after step 2 above. >> >> Rewriting VDB won't help if the user doesn't sync

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, 27 Jul 2014 17:26:27 -0400 Rich Freeman wrote: > But, in that case you can put the necessary ebuilds into your overlay > and then portage can make everything right. Oh? Please explain to us a) how the overlay interaction *actually* works with dynamic dependencies currently, and b) how it

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 08:56, Ciaran McCreesh wrote: > > To me it seems like a simple data model bug that vdb does not get > > updated to reflect the new situation after step 2 above. > > Rewriting VDB won't help if the user doesn't sync at the right time. > Indeed. pkgmove has this problem solved with

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 5:17 PM, Michał Górny wrote: > Dnia 2014-07-27, o godz. 17:08:27 > Rich Freeman napisał(a): >> >> I'd think that portage should update vdb as soon as it detects the >> dependency change. Then B would no longer depend on A in vdb. It >> shouldn't hold onto outdated inform

Re: [gentoo-dev] don't rely on dynamic deps

Dnia 2014-07-27, o godz. 17:08:27 Rich Freeman napisał(a): > On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny wrote: > > Dnia 2014-07-27, o godz. 10:42:19 > > > > Consider the following: > > > > 1. A depends on B, both are installed, > > > > 2. dependency on B is removed, emerge --depclean uninstal

Re: [gentoo-dev] don't rely on dynamic deps

Dnia 2014-07-27, o godz. 22:51:13 Peter Stuge napisał(a): > What is the purpose of keeping only dependencies as-they-were when > the package was installed, if the package manager does not somehow > benefit from that information in the future? You have to ask the one who implemented that. Maybe i

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 4:24 PM, Michał Górny wrote: > Dnia 2014-07-27, o godz. 10:42:19 > > Consider the following: > > 1. A depends on B, both are installed, > > 2. dependency on B is removed, emerge --depclean uninstalls B thanks > to dynamic-deps, > > 3. B is treecleaned (nothing depends on it

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, 27 Jul 2014 22:51:13 +0200 Peter Stuge wrote: > To me it seems like a simple data model bug that vdb does not get > updated to reflect the new situation after step 2 above. Rewriting VDB won't help if the user doesn't sync at the right time. -- Ciaran McCreesh signature.asc Descriptio

Re: [gentoo-dev] don't rely on dynamic deps

Michał Górny wrote: > Consider the following: > > 1. A depends on B, both are installed, > > 2. dependency on B is removed, emerge --depclean uninstalls B thanks > to dynamic-deps, > > 3. B is treecleaned (nothing depends on it), So far I follow. > 4. old version of A is removed (user doesn't

[gentoo-dev] Patches for multilib-build.eclass

The attached patches (attached so that Thunderbird won't mangle them) fix some of the documentation for multilib-build.eclass, then add a couple new functions to simplify some use cases where a flag would be unconditionally enabled for native builds and disabled for non-native builds. -- Jonathan

Re: [gentoo-dev] don't rely on dynamic deps

Dnia 2014-07-27, o godz. 10:42:19 Rich Freeman napisał(a): > On Sun, Jul 27, 2014 at 10:05 AM, "Paweł Hajdan, Jr." > wrote: > > On 7/21/14, 11:52 PM, Alexander Berntsen wrote: > >> Michał has documented the shortcomings of dynamic deps in our wiki[0]. > >> (Thank you!) [...] > >> [0]

Re: [gentoo-dev] Call for help: app-admin/chef

On 07/26/2014 08:38 AM, Manuel Rüger wrote: > Hello, > > app-admin/chef and its related packages are currently maintainer-needed. > > So if you're using chef on Gentoo, this is your chance to step up! > > These packages have some restricting dependencies (e.g. > Currently two version bumps (one

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, 27 Jul 2014 19:16:58 +0200 Peter Stuge wrote: > Ciaran McCreesh wrote: > > Peter Stuge wrote: > > > Ciaran McCreesh wrote: > > > > Rich Freeman wrote: > > > > > What would you do away with? Being able to virtualize > > > > > packages without recompiling everything that depends on them?

Re: [gentoo-dev] don't rely on dynamic deps

Ciaran McCreesh wrote: > Peter Stuge wrote: > > Ciaran McCreesh wrote: > > > Rich Freeman wrote: > > > > What would you do away with? Being able to virtualize packages > > > > without recompiling everything that depends on them? > > > > > > Well that's never worked properly or consistently to b

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, 27 Jul 2014 19:02:05 +0200 Peter Stuge wrote: > Ciaran McCreesh wrote: > > Rich Freeman wrote: > > > What would you do away with? Being able to virtualize packages > > > without recompiling everything that depends on them? > > > > Well that's never worked properly or consistently to beg

Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined

Manuel Rüger wrote: > virtual/libusb-1-r1 depends on either dev-libs/libusb or > sys-freebsd/freebsd-lib. The latter one is only compatible with > libusb-1.0.9, You should know that it's the other way around. freebsd-lib isn't to blame, but >=dev-libs/libusb-1.0.18 is. //Peter pgpDwzxkEwu11.pg

Re: [gentoo-dev] don't rely on dynamic deps

Ciaran McCreesh wrote: > Rich Freeman wrote: > > What would you do away with? Being able to virtualize packages > > without recompiling everything that depends on them? > > Well that's never worked properly or consistently to begin with Please answer the question? //Peter pgpNaSXskEzkH.pgp

[gentoo-dev] Re: About what kind of changes could be stabilized on all arches by the same arch team

El dom, 27-07-2014 a las 07:31 -0700, Matt Turner escribió: > On Sun, Jul 27, 2014 at 7:02 AM, Pacho Ramos wrote: > > Recently I saw some cases where some bugs reported were getting blocked > > by some arch teams being slow to reply. The issue is that this pending > > bug reports were only related

[gentoo-dev] Re: Clarifying if some arch teams allows maintainers to stabilize package on arches they can test

As one of the few people working on ARM64 I’m in agreement. Sure a bug or two is probably going to pop up on account of the change but in the grand scheme this seems like a good move. On Jul 27, 2014, at 10:43 AM, Rick Zero_Chaos Farina wrote: > Signed PGP part > On 07/27/2014 09:55 AM, Pach

Re: [gentoo-dev] Re: don't rely on dynamic deps

Ciaran McCreesh wrote: > Uh huh, so you add an overlay, and suddenly the dependencies for a > random subset of your installed packages change in ways that don't in > any way reflect what you have installed. How is this the desired > behaviour? There are several different cases of dependency data w

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 03:52, Rich Freeman wrote: > Why? Is this about removing an unused dependency? > > > 3. Gentoo simply tweaks the ebuild and doesn't bump [A] > > What is "[A]?" What ebuild was tweaked, and how was it tweaked? > Here, "A" is the derived version of the ebuild of "Foo" the user in

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 11:44 AM, Kent Fredric wrote: > > On 28 July 2014 02:42, Rich Freeman wrote: >> >> One thing I would question in that table is "applied immediately (but >> can break hard when dynamic-deps stop working))." How can dynamically >> removing an "unused dependency" cause somet

Re: [gentoo-dev] don't rely on dynamic deps

On 28 July 2014 02:42, Rich Freeman wrote: > One thing I would question in that table is "applied immediately (but > can break hard when dynamic-deps stop working))." How can dynamically > removing an "unused dependency" cause something to break, setting > aside bugs in the package manager? If

[gentoo-dev] Re: Clarifying if some arch teams allows maintainers to stabilize package on arches they can test

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2014 09:55 AM, Pacho Ramos wrote: > Today some user on IRC noted that there were some doubts about if > developers are allowed to stabilize packages they maintain when they are > able to test on

Re: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined

On Sat, Jul 26, 2014 at 01:45:46PM -0400, Jonathan Callen wrote: *snip* > If you want to say "At most one of the flags 'foo', 'bar', and 'baz' > may be selected", then you say it like so (requires EAPI=5): > > REQUIRED_USE="?? ( foo bar baz )" > > If you want to say "Exactly one of the flags

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, 27 Jul 2014 11:09:05 -0400 Rich Freeman wrote: > On Sun, Jul 27, 2014 at 10:59 AM, Ciaran McCreesh > wrote: > > On Sun, 27 Jul 2014 16:56:17 +0200 > > ""Paweł Hajdan, Jr."" wrote: > >> It seems really tricky to correctly reason about dependency > >> resolution. > > > > It's actually very

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 10:59 AM, Ciaran McCreesh wrote: > On Sun, 27 Jul 2014 16:56:17 +0200 > ""Paweł Hajdan, Jr."" wrote: >> It seems really tricky to correctly reason about dependency >> resolution. > > It's actually very easy if you do away with all the things that are > making it unnecessar

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, 27 Jul 2014 16:56:17 +0200 ""Paweł Hajdan, Jr."" wrote: > It seems really tricky to correctly reason about dependency > resolution. It's actually very easy if you do away with all the things that are making it unnecessarily complicated... Nearly all of the complexity is self-inflicted. -

Re: [gentoo-dev] don't rely on dynamic deps

On 7/27/14, 4:42 PM, Rich Freeman wrote: > With dynamic deps you'd need to revbump if there is a linking change. > Otherwise portage would just allow the dependency to be removed, and > then linking will break, since the executable is unnecessarily linked > to the dependency (in that scenario). Ri

Re: [gentoo-dev] don't rely on dynamic deps

Dnia 2014-07-27, o godz. 16:05:34 ""Paweł Hajdan, Jr."" napisał(a): > On 7/21/14, 11:52 PM, Alexander Berntsen wrote: > > Michał has documented the shortcomings of dynamic deps in our wiki[0]. > > (Thank you!) [...] > > [0] > >

Re: [gentoo-dev] don't rely on dynamic deps

On Sun, Jul 27, 2014 at 10:05 AM, "Paweł Hajdan, Jr." wrote: > On 7/21/14, 11:52 PM, Alexander Berntsen wrote: >> Michał has documented the shortcomings of dynamic deps in our wiki[0]. >> (Thank you!) [...] >> [0] > > There's one

Re: [gentoo-dev] don't rely on dynamic deps

On 7/21/14, 11:52 PM, Alexander Berntsen wrote: > Michał has documented the shortcomings of dynamic deps in our wiki[0]. > (Thank you!) [...] > [0] There's one more thing I'd like to ask about: For "Minor linking change w/ depen

[gentoo-dev] About what kind of changes could be stabilized on all arches by the same arch team

Recently I saw some cases where some bugs reported were getting blocked by some arch teams being slow to reply. The issue is that this pending bug reports were only related with changes that weren't arch dependent. Some cases that comes to my mind now: - Changes only adding systemd unit files - Ch

[gentoo-dev] Clarifying if some arch teams allows maintainers to stabilize package on arches they can test

Today some user on IRC noted that there were some doubts about if developers are allowed to stabilize packages they maintain when they are able to test on relevant arches (I guess this would benefit amd64 and x86 mostly as it's likely more spread). If I don't misremember amd64 team allows that, b

Re: [gentoo-dev] Re: don't rely on dynamic deps

Dnia 2014-07-27, o godz. 14:42:24 Samuli Suominen napisał(a): > > On 26/07/14 15:49, Ciaran McCreesh wrote: > > On Sat, 26 Jul 2014 12:41:16 + (UTC) > > Martin Vaeth wrote: > >> hasufell wrote: > >>> Dynamics deps are already broken, not consistently enabled (e.g. > >>> when subslots are i

Re: [gentoo-dev] Avoiding rebuilds

Ulrich Mueller: >> On Sun, 27 Jul 2014, Martin Vaeth wrote: > >> Kent Fredric wrote: >>> -r1.1 weirdness feels like it may cause more problems than it solves. > >> So far, nobody pointed out any problem which would be caused by -r1.1. >> Which is not surprising, since the idea is that -r1.1

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sun, 27 Jul 2014 14:42:24 +0300 Samuli Suominen wrote: > We just succesfully converted ~300 ebuilds in tree without revision > bumps from virtual/udev[gudev,introspection,static-libs] > to virtual/libudev and virtual/libgudev > Tested it on multiple boxes, went fine. Testing can't prove that i

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sun, Jul 27, 2014 at 8:31 AM, hasufell wrote: > > I'm eager to hear how you want to make subslots work with dynamic deps. > > := gets converted to :${SLOT}/${SUBSLOT} in vardb and this is used to > trigger the rebuilds. > > How do you record the subslot a package was built against in the live t

Re: [gentoo-dev] Re: don't rely on dynamic deps

Samuli Suominen: > > On 27/07/14 14:50, hasufell wrote: >> Samuli Suominen: >>> On 26/07/14 15:49, Ciaran McCreesh wrote: On Sat, 26 Jul 2014 12:41:16 + (UTC) Martin Vaeth wrote: > hasufell wrote: >> Dynamics deps are already broken, not consistently enabled (e.g. >> wh

Re: [gentoo-dev] Behaving productively on the list

Andreas K. Huettel: > Am Sonntag, 27. Juli 2014, 14:04:00 schrieb hasufell: I'm not sure if you realize that you just disabled dynamic deps support on most of those converted ebuilds. >>> >>> PLEASE, everyone, don't just make statements like the the one above ^ but >>> instead explain wha

[gentoo-dev] CMake 3.0 unmasking

Hi all, your favorite build tool =dev-util/cmake-3.0.0 just hit the tree. If no regressions show up, we would like to unmask it in ~30 days. Please test it! Greetings, -- Johannes Huber (johu) Gentoo Linux Developer / KDE Team GPG Key ID F3CFD2BD signature.asc Description: This is a digitally

Re: [gentoo-dev] Avoiding rebuilds (was: don't rely on dynamic deps)

On Sun, Jul 27, 2014 at 6:16 AM, Ulrich Mueller wrote: > I wonder if it wouldn't be saner to leave our revision syntax > untouched. > > Instead, one could introduce a variable INSTALL_VERSION that would > default to ${PVR} but could be set to the version of a previous ebuild > instead. The PM coul

Re: [gentoo-dev] Behaving productively on the list

Am Sonntag, 27. Juli 2014, 14:04:00 schrieb hasufell: > >> I'm not sure if you realize that you just disabled dynamic deps support > >> on most of those converted ebuilds. > > > > PLEASE, everyone, don't just make statements like the the one above ^ but > > instead explain what has happened and be

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 27/07/14 14:50, hasufell wrote: > Samuli Suominen: >> On 26/07/14 15:49, Ciaran McCreesh wrote: >>> On Sat, 26 Jul 2014 12:41:16 + (UTC) >>> Martin Vaeth wrote: hasufell wrote: > Dynamics deps are already broken, not consistently enabled (e.g. > when subslots are in use)

Re: [gentoo-dev] Re: don't rely on dynamic deps

On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric wrote: > > In a "no dynamic deps, period" scenario, this just strikes me as 2 flavours > of the same weirdness, -r2 and -r1.1 are just equally weird choices to make > if the ebuild itself doesn't change at all. You have a good point here. With this p

Re: [gentoo-dev] Behaving productively on the list

Andreas K. Huettel: > Am Sonntag, 27. Juli 2014, 13:50:43 schrieb hasufell: > >>> So, broken? Far from it. More like essential feature. > >> >> I'm not sure if you realize that you just disabled dynamic deps support >> on most of those converted ebuilds. > > PLEASE, everyone, don't just make sta

Re: [gentoo-dev] Behaving productively on the list

Am Sonntag, 27. Juli 2014, 13:50:43 schrieb hasufell: > > So, broken? Far from it. More like essential feature. > > I'm not sure if you realize that you just disabled dynamic deps support > on most of those converted ebuilds. PLEASE, everyone, don't just make statements like the the one above ^

Re: [gentoo-dev] Re: don't rely on dynamic deps

"Paweł Hajdan, Jr.": > On 7/27/14, 1:42 PM, Samuli Suominen wrote: >> Only one person said he had to manually build 2 GNOME related packages, >> simple-scan and something else >> >> So, broken? Far from it. More like essential feature. >> >> People have just listed some known races dynamic deps hav

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 7/27/14, 1:42 PM, Samuli Suominen wrote: > Only one person said he had to manually build 2 GNOME related packages, > simple-scan and something else > > So, broken? Far from it. More like essential feature. > > People have just listed some known races dynamic deps have, and I take > those races

Re: [gentoo-dev] Re: don't rely on dynamic deps

Samuli Suominen: > > On 26/07/14 15:49, Ciaran McCreesh wrote: >> On Sat, 26 Jul 2014 12:41:16 + (UTC) >> Martin Vaeth wrote: >>> hasufell wrote: Dynamics deps are already broken, not consistently enabled (e.g. when subslots are in use) >>> Just to make it clear: No, dynamic deps a

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 26/07/14 15:49, Ciaran McCreesh wrote: > On Sat, 26 Jul 2014 12:41:16 + (UTC) > Martin Vaeth wrote: >> hasufell wrote: >>> Dynamics deps are already broken, not consistently enabled (e.g. >>> when subslots are in use) >> Just to make it clear: No, dynamic deps are not broken. > Yes they a

[gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-apach

# Pacho Ramos (27 Jul 2014) # Upstream dead, fails tests, nothing needs it. # Removal in a month (#336256) app-crypt/opencdk # Pacho Ramos (27 Jul 2014) # Upstream dead for ages, fails to build due underlinking, # nothing needs it (#367573). Removal in a month. net-dialup/gnome-ppp # Pacho Ramo

Re: [gentoo-dev] Re: don't rely on dynamic deps

On 27 July 2014 19:16, Martin Vaeth wrote: > Not at all, it is completely identical to a revision bump: > If you would use -r2 instead of -r1.1, you also would end up > in -r1 and -r2 being identical. > Actually, in both cases, you would *remove* -r1, since -r1 is incorrect > since it should have

[gentoo-dev] Avoiding rebuilds (was: don't rely on dynamic deps)

> On Sun, 27 Jul 2014, Martin Vaeth wrote: > Kent Fredric wrote: >> -r1.1 weirdness feels like it may cause more problems than it solves. > So far, nobody pointed out any problem which would be caused by -r1.1. > Which is not surprising, since the idea is that -r1.1 cannot be > distinguished

[gentoo-dev] Re: don't rely on dynamic deps

hasufell wrote: >>> Ciaran McCreesh wrote: > > This looks like a private lesson *If* there is a corresponding passage in PMS, it seems to be somewhat hidden (as I pointed out) and certainly many others haven't found this, either. (As the eix maintainer, I know PMS probably better than many in th

[gentoo-dev] Re: don't rely on dynamic deps

Kent Fredric wrote: > On 27 July 2014 02:12, Martin Vaeth wrote: >> >> Do not forget modification of eclasses which then require mass bumps! > > I'm curious what the -r1.1 technique would do here. > > I mean, wouldn't that mean you have 2 ebuilds that are identical except for > the '.1' simply du