Re: [gentoo-dev] New PDEPEND behaviour.
On Mittwoch, 25. Juli 2007, Vlastimil Babka wrote: > A: PDEPEND="B" > B: DEPEND="A" > > If this is what you call RDEPEND conceptually broken, then sorry for > useles try to explain it :) Maybe package manager could be smart enough > and relax the RDEPEND in such cases itself, maybe it's better to say > that via PDEPEND explicitly... Of course a valid example - and yes, that's something the package manager should care about. Admitted, "conceptually broken" was a bit harsh, still both, that a pure runtime dependency gets built before the ebuild needing it by default and the need for PDEPEND seem ugly to me. Carsten signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Gentoo-project and gentoo-dev-announce mailing lists created.
Hi, Many people may already have noticed it, but here's an announcement for those who haven't yet. Gentoo-project and gentoo-dev-announce mailing lists created. These two mailing lists have been created to improve the flow of information and create an appropriate channel for non-technical discussions. The gentoo-project list is for all non-technical discussions currently found on the development mailing list, which should only be used for technical discussion. The gentoo-dev-announce mailing list will feature announcements relevant to the development process, which makes it easier to stay up to date on the development process. More information (including how to subscribe) can be found on http://www.gentoo.org/main/en/lists.xml cheers, Wernfried -- Wernfried Haas (amne) - amne (at) gentoo.org Gentoo Forums - http://forums.gentoo.org forum-mods (at) gentoo.org #gentoo-forums (freenode) pgpdbOxEewNXq.pgp Description: PGP signature
Re: [gentoo-dev] New PDEPEND behaviour.
Carsten Lohrke wrote: Well, I should point out where I come from. There is no need to install a pure runtime dependency before the ebuild pulling it in. If pure runtime dependencies would be handled this way, there would be no need for PDEPEND at all. I consider the current way Portage handles pure runtime dependencies (causing the need for the artificial PDEPEND in the first place) as conceptually broken. There are uses for it: A: RDEPEND="B" B: RDEPEND="A" Here you really don't need PDEPEND because in current portage, pure runtime dependency indeed doesn't have to be satisfied before the ebuild pulling it. But consider this: A: PDEPEND="B" B: DEPEND="A" Here you can't use RDEPEND instead of PDEPEND, because DEPEND="A" says the package must be merged in a working state, thus *with all its RDEPENDs* and thus it would cause circular deps. PDEPEND is a way to relax this for such cases. If this is what you call RDEPEND conceptually broken, then sorry for useles try to explain it :) Maybe package manager could be smart enough and relax the RDEPEND in such cases itself, maybe it's better to say that via PDEPEND explicitly... -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wednesday 25 of July 2007 16:18:04 Ciaran McCreesh wrote: > Give one example of a legitimate use of dependencies that will break by > this change. In your answer, consider that someone might install the > post package as a target without having its dependencies installed. I am not saying it's breaking something, I just wouldn't except such a behaviour after reading the docs. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Mittwoch, 25. Juli 2007, Brian Harring wrote: > I suggest you in the future check out what actually was changed, and > do some testing- both the original poster, and yourself are missing > what is occuring here Uh, thanks, I never was fond of reading the code of Portage, so I took Piotr's point as given. > Note I said 'shift'. It tries to place it earlier in the graph, while > *still* maintaining the constraints of kdnssd-avahi- namely the > kdelibs dependency. > > Via that dep, kdnssd-avahi *requires* kdelibs to be installed first, > and portage honors that- it just now tries to get kdnssd-avahi merged > as soon as possible after kdelibs due to their PDEPEND relationship > (try it if in doubt, it lineralizes it properly). > > The cases where it doesn't, are when the constraints are already > satisfied- kdelibs already is merged, basically. There is a change in > placement there, but considering the data involved, wouldn't label it > a regression- same issue can, and does occur in multiple other ways. That's fine. > > The latter. > > Former. The ebuild manpage is a bit loose in it's description of what > PDEPEND does. Well, I should point out where I come from. There is no need to install a pure runtime dependency before the ebuild pulling it in. If pure runtime dependencies would be handled this way, there would be no need for PDEPEND at all. I consider the current way Portage handles pure runtime dependencies (causing the need for the artificial PDEPEND in the first place) as conceptually broken. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New PDEPEND behaviour.
On Wednesday 25 of July 2007 16:18:06 Doug Goldstein wrote: > I've read the bugs you've referenced and it just sounds like a bug in > the Paludis ebuilds not having the proper depends. > > This e-mail was just some fear mongering on behalf of Paludis devs. I think you misread my e-mail completly and btw. Paludis is following the same rules: A: PDEPEND="B" B: RDEPEND="A" Both portage and paludis can end up installing B before A and it seems there is nothing wrong with it other than that I think it doesn't match the docs. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, 25 Jul 2007 10:24:14 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Wed, 25 Jul 2007 08:46:43 -0400 > > Doug Goldstein <[EMAIL PROTECTED]> wrote: > > > >> Now how in the world do you pull a depend that needs to be merged > >> AFTER the original package? > > > > You make the after package DEPEND upon the before package. > > except the user only has to emerge ABC, and as such XYZ needs to be > pulled in but AFTER ABC gets emerged. Your answer does not handle > that situation. It's OBVIOUS (and in all cases in the tree) XYZ > already DEPENDs on ABC. ABC: PDEPEND="XYX" XYZ: DEPEND="ABC" That's all that's needed to force correct ordering. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, 25 Jul 2007 10:28:27 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > They do. You didn't understand the question at all. Examples off the > top of my head.. > > ipw2100, ipw2200, ivtv, mythtv. > > I want ivtv support... > > emerge ivtv > > It should pull in pvr-firmware immediately after since that pkg > contains the firmware for the driver. ivtv: PDEPEND="pvr-firmware" pvr-firmware: DEPEND="ivtv" -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, 25 Jul 2007 10:18:06 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > This e-mail was just some fear mongering on behalf of Paludis devs. No no. It's on behalf of Piotr, who is a Gentoo developer who happens to not understand dependency resolution. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New PDEPEND behaviour.
Piotr Jaroszyński wrote: > We need to update docs or harass zmedico to force PDEPEND to be pulled as > soon > as possible but not before the pkg that pulls it. There is another problem with PDEPEND that I've run into: if you are doing an emerge that fails some time after the package containing the PDEPEND builds but *before* the depended-on package builds successfully, the dependency will not be "remembered" as needed on the next emerge (unless you do a resume, of course). So, basically, the dependency gets forgotten. The new behavior discussed here makes this scenario less likely but does not eliminate it. -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, 25 Jul 2007 14:51:55 +0200 Carsten Lohrke <[EMAIL PROTECTED]> wrote: > And I'm pretty sure nearly everyone using PDEPEND in his ebuilds > relies on Portage building the PDEPEND not before the ebuild, which > lists it. And I'm pretty sure they don't, since they have the post package DEPENDing upon the pre package anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New PDEPEND behaviour.
Ciaran McCreesh wrote: On Wed, 25 Jul 2007 14:51:55 +0200 Carsten Lohrke <[EMAIL PROTECTED]> wrote: And I'm pretty sure nearly everyone using PDEPEND in his ebuilds relies on Portage building the PDEPEND not before the ebuild, which lists it. And I'm pretty sure they don't, since they have the post package DEPENDing upon the pre package anyway. They do. You didn't understand the question at all. Examples off the top of my head.. ipw2100, ipw2200, ivtv, mythtv. I want ivtv support... emerge ivtv It should pull in pvr-firmware immediately after since that pkg contains the firmware for the driver. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, Jul 25, 2007 at 02:51:55PM +0200, Carsten Lohrke wrote: > On Mittwoch, 25. Juli 2007, Piotr Jaroszyński wrote: > > As a result of bug #180045 PDEPENDs can be now merged even before the > > package that pulls them. Zmedico says that's intended behaviour > > Well, then what our Portage devs think the intended behaviour should be is a > bug. E.g. in the case the bug refers to, we rely on Portage building > kdnssd-avahi after kdelibs (otherwise it simply would fail), but before any > other ebuild that might need kdnssd-avahi. I suggest you in the future check out what actually was changed, and do some testing- both the original poster, and yourself are missing what is occuring here (if it's any consolation, I missed the real cause of 186517 initially too :). The portage change is to shift the placement of PDEPENDed nodes as early as possible- specifically to fix cases where deps are a bit screwed up (like 180045, kdnssd-avahi/kdelibs). Note I said 'shift'. It tries to place it earlier in the graph, while *still* maintaining the constraints of kdnssd-avahi- namely the kdelibs dependency. Via that dep, kdnssd-avahi *requires* kdelibs to be installed first, and portage honors that- it just now tries to get kdnssd-avahi merged as soon as possible after kdelibs due to their PDEPEND relationship (try it if in doubt, it lineralizes it properly). The cases where it doesn't, are when the constraints are already satisfied- kdelibs already is merged, basically. There is a change in placement there, but considering the data involved, wouldn't label it a regression- same issue can, and does occur in multiple other ways. > And I'm pretty sure nearly > everyone using PDEPEND in his ebuilds relies on Portage building the PDEPEND > not before the ebuild, which lists it. No one has relied on that in my experience. They've relied on PDEPEND being satisfied, but not required to be satisfied by the time the PDEPENDer is considered 'satisfied' buildplan wise. I strongly suspect folks echoing that sentiment are missing that a PDEPEND'ed nodes' DEPEND/RDEPEND *must* be satisfied prior to it being merged, and are missing what PDEPEND means to the resolver. > > We need to update docs or harass zmedico to force PDEPEND to be pulled as > > soon as possible but not before the pkg that pulls it. > > The latter. Former. The ebuild manpage is a bit loose in it's description of what PDEPEND does. As cardoe commented, the flaw that folks are hitting in 186517 is a data flaw (the data is bad); it's not a flaw in the resolver behaviour. Feed it bad data, it's going to do stupid things basically :) ~harring pgp1KmGPzjTuI.pgp Description: PGP signature
Re: [gentoo-dev] New PDEPEND behaviour.
Ciaran McCreesh wrote: On Wed, 25 Jul 2007 08:46:43 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: Now how in the world do you pull a depend that needs to be merged AFTER the original package? You make the after package DEPEND upon the before package. except the user only has to emerge ABC, and as such XYZ needs to be pulled in but AFTER ABC gets emerged. Your answer does not handle that situation. It's OBVIOUS (and in all cases in the tree) XYZ already DEPENDs on ABC. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, 25 Jul 2007 14:08:39 +0200 Piotr Jaroszyński <[EMAIL PROTECTED]> wrote: > We need to update docs or harass zmedico to force PDEPEND to be > pulled as soon as possible but not before the pkg that pulls it. Give one example of a legitimate use of dependencies that will break by this change. In your answer, consider that someone might install the post package as a target without having its dependencies installed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New PDEPEND behaviour.
Piotr Jaroszyński wrote: Hello, As a result of bug #180045 PDEPENDs can be now merged even before the package that pulls them. Zmedico says that's intended behaviour and PDEPEND is really a RDEPEND, but with a ability to resolve circular deps: circular DEPEND <-> RDEPEND can't be resolved while circular DEPEND <-> PDEPEND can. Random behaviour occurs when there is a circular RDEPEND <-> PDEPEND, e.g. bug #186517. We need to update docs or harass zmedico to force PDEPEND to be pulled as soon as possible but not before the pkg that pulls it. Actually in a follow up... I've read the bugs you've referenced and it just sounds like a bug in the Paludis ebuilds not having the proper depends. This e-mail was just some fear mongering on behalf of Paludis devs. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, 25 Jul 2007 08:46:43 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > Now how in the world do you pull a depend that needs to be merged > AFTER the original package? You make the after package DEPEND upon the before package. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite: media-sound/playmidi
On Wed, 25 Jul 2007 14:22:21 +0300 Samuli Suominen <[EMAIL PROTECTED]> wrote: > # Samuli Suominen <[EMAIL PROTECTED]> (25 Jul 2007) > # Broken, doesn't build -- using OSS and GTK+-1.2. > # Last release from upstream 9 years ago. > # Masked for removal in 30 days. > media-sound/playmidi Undo this, fixed in -r2 thanks to Diego :) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Mittwoch, 25. Juli 2007, Piotr Jaroszyński wrote: > As a result of bug #180045 PDEPENDs can be now merged even before the > package that pulls them. Zmedico says that's intended behaviour Well, then what our Portage devs think the intended behaviour should be is a bug. E.g. in the case the bug refers to, we rely on Portage building kdnssd-avahi after kdelibs (otherwise it simply would fail), but before any other ebuild that might need kdnssd-avahi. And I'm pretty sure nearly everyone using PDEPEND in his ebuilds relies on Portage building the PDEPEND not before the ebuild, which lists it. > We need to update docs or harass zmedico to force PDEPEND to be pulled as > soon as possible but not before the pkg that pulls it. The latter. Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New PDEPEND behaviour.
Piotr Jaroszyński wrote: Hello, As a result of bug #180045 PDEPENDs can be now merged even before the package that pulls them. Zmedico says that's intended behaviour and PDEPEND is really a RDEPEND, but with a ability to resolve circular deps: circular DEPEND <-> RDEPEND can't be resolved while circular DEPEND <-> PDEPEND can. Random behaviour occurs when there is a circular RDEPEND <-> PDEPEND, e.g. bug #186517. We need to update docs or harass zmedico to force PDEPEND to be pulled as soon as possible but not before the pkg that pulls it. Now how in the world do you pull a depend that needs to be merged AFTER the original package? i.e. Package ABC and Package XYZ... Package XYZ is a series of config files and data for Package ABC. The files of XYZ need to be owned by user abc which gets created by Package ABC. Those files also need to be installed in /usr/share/abc, which gets created by Package ABC. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Lastrite: net-misc/bird
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 # Tony Vroon <[EMAIL PROTECTED]> (25 Jul 2007) # Unsuitable for IXP route server usage # Seems incomplete for most other workloads # Lost interest in this package, removal on 25 Aug 2007. net-misc/bird -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGp0Xzp5vW4rUFj5oRCKVPAJsHOIpdzf6aTPOUSL0vMKLa1lETJgCgrO3F rGnlWumk541kgvAI1oHr50g= =4IHP -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
On Wed, Jul 25, 2007 at 02:08:39PM +0200, Piotr Jaroszy??ski wrote: > Hello, > > As a result of bug #180045 PDEPENDs can be now merged even before the package > that pulls them. Zmedico says that's intended behaviour and PDEPEND is really > a RDEPEND, but with a ability to resolve circular deps: > circular DEPEND <-> RDEPEND can't be resolved while circular DEPEND <-> > PDEPEND can. > Random behaviour occurs when there is a circular RDEPEND <-> PDEPEND, e.g. > bug > #186517. > > We need to update docs or harass zmedico to force PDEPEND to be pulled as > soon > as possible but not before the pkg that pulls it. PDEPEND (just like RDEPEND), can, and always has been *able* to be satisfied prior to the node that requires it- the name may suck, but it's better then BREAK_RDEPEND_CYCLES, thus PDEPEND; it's never been viewed as a literal "it must be post" however. Semi curious when the ebuild manpage picked up that description also- would expect its just a bad choice of words. If in doubt, suggest you do some experiments with earlier portage versions, explicitly trying to force a node that is PDEPEND'd upon to come prior- ought to occur fine. Basically, you're arguing based upon *most* PDEPEND'd nodes dep'ing on the original PDEPENDer (a cycle, thus with PDEPEND breaking it, the PDEPEND target coming first due to resolution rules) - not on rules of PDEPEND. Either way, proposing that PDEPEND (a cycle breaking RDEPEND), be literal post is likely going trigger some fun fallout with the existing consumers of it. Suggest you investigate those before pushing this idea further. On the offchance there isn't nasty fallout from your proposal, still view it as -1 for the change. ~harring pgpHZSvRJgHyO.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Forbid using versions in DESCRIPTION
On Tuesday 24 July 2007, Luca Barbato wrote:
> Marijn Schouten (hkBst) wrote:
> > That would make it
> > impossible to use ${PV} and more importantly also remove some
> > duplication.
>
> It isn't duplicated, description is per ebuild and could change,
> metadata is for the package as whole.
can you point out a package where this is actually needed let alone used ?
none of our utilities expose the DESCRIPTION on a per-ebuild basis, only
per-package
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Forbid using versions in DESCRIPTION
On Tuesday 24 July 2007, Ciaran McCreesh wrote: > Petteri Räty <[EMAIL PROTECTED]> wrote: > > But is there anything that makes use of version specific DESCRIPTION > > atoms? > > Yep. Have a look at sys-devel/gcc for example. Some versions include > various extensions, and say so in DESCRIPTION. eh, i'm not really partial to such enumeration, not that it really matters considering most search programs show 1 DESCRIPTION (the latest) easy enough to expound upon in a long description -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] New PDEPEND behaviour.
Hello, As a result of bug #180045 PDEPENDs can be now merged even before the package that pulls them. Zmedico says that's intended behaviour and PDEPEND is really a RDEPEND, but with a ability to resolve circular deps: circular DEPEND <-> RDEPEND can't be resolved while circular DEPEND <-> PDEPEND can. Random behaviour occurs when there is a circular RDEPEND <-> PDEPEND, e.g. bug #186517. We need to update docs or harass zmedico to force PDEPEND to be pulled as soon as possible but not before the pkg that pulls it. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Lastrite: media-sound/playmidi
# Samuli Suominen <[EMAIL PROTECTED]> (25 Jul 2007) # Broken, doesn't build -- using OSS and GTK+-1.2. # Last release from upstream 9 years ago. # Masked for removal in 30 days. media-sound/playmidi -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: New lists and their usage
Chris Gianelloni wrote: >> Yeah, you should take that to -project or some other suitable list :P > > Once some consensus is made and it actually becomes policy, sure. Until > then, I'm going to continue to use this list for the same things it's > been used for up until now. Once we've agreed upon how the lists should > be used, then I see no issue with using them that way, meaning *this* > conversation does belong here, as there's been no consensus amongst our > developer pool, nor a completed Council decision to change the policy. > Well I think there's been a consensus that project is for non-technical discussion. Usage policy for lists would seem to fall under that. > Like I said, the two proposals I had seen were: > > - gentoo-dev-announce > - gentoo-project > > I hadn't seen anyone asking for both, so we've now got to figure out > whether to drop one list or repurpose one of them. Personally, I'm for > repurposing gentoo-dev-announce to be a global "development" announce > list with no reply-to munging/filtering and developer-only posting. I > think doing this would be complimentary to gentoo-project and would be > useful to me, allowing me to know about conversations on other lists and > allowing *me* to *choose* when I want to participate, which is a vast > improvement from what we have had until now. > That sounds like an effective use of dev-announce, although it would make more sense to keep it as pure announcements, which would mean reply-to would be dev. Otherwise, it could become the public dev-only mailing list which was proposed for this list, and there was definitely no consensus established for that move. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Nominations Update
On Mon, 23 Jul 2007 17:38:16 -0700 Christina Fullam <[EMAIL PROTECTED]> wrote: Although I've mentioned quite a bit, I feel that some of these questions still need addressing... This lot can probably be added to my candidate info stuffs/platform thingie on the site... [..snip..] > 1) What you will do > 2) Why you will do it > 3) How you will do it Black magik. Encouragement of ideas such as project updates, at least some support and/or contributions to those who work on other Gentoo-based distros, taking their ideas and contributions into the tree, etc, etc. One possible idea would be to encourage people to use one channel for primary communications, currently, many people make decisions (in private?) on IRC, then "forget" to tell everyone else about the decision... If we were all encouraged to make decisions on relevant email aliases, on the right mailing list, etc, etc, there would be less people missing out. The -project, -dev-announce and -dev setup we've got at the moment seems to be a start in the right direction from what I can see so far. It does require more time to wear in before it can really be seen as a success or a failure. > 4) What is the timescale for doing it This depends on who is involved with the efforts, who agrees, who wants to bring up (potentially) silly arguments, etc, etc. It's not really possible to set a deadline for something when you don't know who you will be working with. > 5) What experience do you have with this or a similar role I'm the lead of the Gentoo/*BSD team, the Gentoo/Alt ATs and the Bugday team. The latter two teams do require quite a bit of user interaction, which could be useful for the implementation of some of my ideas. > 6) Why do you think you are qualified Hrm, how different is this question to the question above? Meh. Well, I suppose I am quite vocal - I speak to people a lot. I'm involved with a local LUG. See answer to question above... > 7) How you plan to balance a council role with your current Gentoo > role Council will take precedence over most/all of my other roles. I will probably also be dropping out of some of the teams/projects where I have been relatively inactive. > 8) How much time can you dedicate to the council role Hmm. Well, around 7.5hrs a day if needs be. I should be able to pull out more hours from the hat, dependant on my school timetable for the next academic year. [..snip..] signature.asc Description: PGP signature
