Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote: On Sat, 14 Jun 2008 22:16:36 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Bernd Steinhauser wrote: Wow, impressive. Actually, you can't be serious... I am. GLEP 54 for quite some time now and it works very well. adds nothing to - and sets usage as is. I just don't see any benefit from your proposal, on the contrary there are issues. No. Yes. No, I spent some emails already before this one shorter addressing this, so a plain No is the right answer to reiterating. And that includes the ordering. No. Yes. Question answered again far before, if you dislike the answer you could pick that part of the thread and comment there. Reiterated question gets shorter replies. About glep-54: emerge code-scm what should fetch? (given that code is an editor and code-scm is a plugin adding scm support...) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Tue, 17 Jun 2008 10:59:37 +0200 Luca Barbato [EMAIL PROTECTED] wrote: About glep-54: emerge code-scm what should fetch? (given that code is an editor and code-scm is a plugin adding scm support...) code-scm. There is no way of distinguishing between a c/p and a c/p-v, which is why you have to use the =. GLEP 54 does not change that. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 22:16:36 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Bernd Steinhauser wrote: Wow, impressive. Actually, you can't be serious... I am. GLEP 54 for quite some time now and it works very well. adds nothing to - and sets usage as is. I just don't see any benefit from your proposal, on the contrary there are issues. No. Yes. And that includes the ordering. No. Yes. GLEP 54 is fine as is. Not one person has expressed approval at your current proprosal, and many people from many different viewpoints have expressed disapproval. Simplying saying no does not make these criticisms go away. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
В Сбт, 14/06/2008 в 19:28 +0200, Luca Barbato пишет: I don't see disadvantages, all I wanted is a simple way to archive this: [# emaint -r ffmpeg ... # emerge ffmpeg -L ... egen ... skipped most of stuff] Your example shows that .live ebuilds fix different issue. What you are suggesting are not live ebuilds but automation for snapshot creation. And I don't see why you need .live ebuilds for this. Just create ffmpeg-0.4.9_pre1235.ebuild and then increment number in _pre part, create snapshot and be done (btw, automation of snapshot creation was already discussed as pkg_maint() or maint_...(); bug 185567). -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote: On Fri, 13 Jun 2008 13:35:52 +0200 Marius Mauch [EMAIL PROTECTED] wrote: Ignoring possible semantic issues for the moment, I'd be against this simply because it would require the PM to be aware of the current revision of the repository and to transform it into a integer value (trivial for SVN, not so trivial for CVS for example). Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) The former, as Marius said, requires knowledge of how to get a sane revision id from every SCM we want to support to be built into the package manager. I wonder if instead of rev id, we could use a timestamp to fill in _pre. It's not ideal but it narrows the checkout down somewhat. Also, we could use pkg_info to report revision numbers (for those SCM's that have such a thing). The combination of the two might be enough - you'd have the revision you installed, when you installed it, and an automatic incrementor for those ppl who like those kinds of things. I like better single digits but it's more or less the same as structure and code. If a dev wants to force a reinstall because of ebuild or patch changes or whatever, they should still be able to use -rX as usual. A lot of projects work like this: * trunk/ is current development, and is ahead of any release. * branches/0.26/ is forked from trunk/ when 0.26 is released, and is equal to or ahead of any 0.26 release. How does your proposal handle this? I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... That's an upstream issue, all we should care is about getting a version value that makes sense for us, better if it does for them. As for an ebuild tracking trunk, I guess we're back to -.live. ;P or just keep in mind that even trunk changes enough that you need to update the ebuild thus makes sense use a next supposed version. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato [EMAIL PROTECTED] wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato [EMAIL PROTECTED] wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato [EMAIL PROTECTED] wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. And what triggers said generation? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato [EMAIL PROTECTED] wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. And what triggers said generation? I already replied in this thread, I guess the information is getting too spread (and will be a pain put it back to the glep) =/ dev-zero pointed out that he would like to trigger the generation on a timely basis, I wanted to trigger it on the sync event, others had other opinion, so the best would be have it as separate phase and trigger it from the maint application. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:04:45 +0200 Luca Barbato [EMAIL PROTECTED] wrote: It will be available once you trigger again the generation or if you put a normal ebuild with such name. And what triggers said generation? I already replied in this thread, I guess the information is getting too spread (and will be a pain put it back to the glep) =/ dev-zero pointed out that he would like to trigger the generation on a timely basis, I wanted to trigger it on the sync event, others had other opinion, so the best would be have it as separate phase and trigger it from the maint application. And none of those are even close to a reasonable, implementable idea. I'm getting the impression you really didn't think this through at all before mailing your proposal. I suggest you go back to the start, work out use cases, package manager interactions, how if at all ebuilds will need to be adapted and several examples. There's a big difference between a few vague ideas and the foundations for an implementable proposal. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 12:04:45 +0200 Luca Barbato [EMAIL PROTECTED] wrote: It will be available once you trigger again the generation or if you put a normal ebuild with such name. And what triggers said generation? I already replied in this thread, I guess the information is getting too spread (and will be a pain put it back to the glep) =/ dev-zero pointed out that he would like to trigger the generation on a timely basis, I wanted to trigger it on the sync event, others had other opinion, so the best would be have it as separate phase and trigger it from the maint application. And none of those are even close to a reasonable, implementable idea. They are implementable. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:45:31 +0200 Luca Barbato [EMAIL PROTECTED] wrote: And none of those are even close to a reasonable, implementable idea. They are implementable. They're really not. You haven't even begun to discuss: * What generation looks like. * How to select which ebuilds to trigger generation for. * When specifically to trigger generation. * Whether generation failure is possible, and what happens if it is. * What to do when generated information is required but not available. * The security implications of the previous point. * What the impact upon upstream servers is, if any. * How generation fits in with users doing system updates. * How generation fits in with the highly differing frequencies of upstream updates. * How generation can be made to fit in without changes to the version spec, whilst still 'making sense' and doing the right thing. The answers to all of the above are highly non-trivial. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato [EMAIL PROTECTED] wrote: Ryan Hill wrote: I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... That's an upstream issue, all we should care is about getting a version value that makes sense for us, better if it does for them. I think upstream use release branches correctly here, and it's the most widespread use. There's some real examples where .live = _pre has problems. * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when it's released. * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse. * x11-wm/enlightenment: latest release is 0.16.8.13, current live ebuild is 0.16.. If we use .live here we'd need either 0.16..live (which is quite pointless) or 0.16.8.14.live which would need to be updated after every minor release. 0.17.live is not a possibility at all since 0.17 is a rewrite from scratch and an entire different application. * media-sound/amarok: live version is 1.4.. Next version is 2.0, but that's a different branch so I'd expect 2.0.live to give me the latest 2.0 version available, not 1.4's. With the current proposal, .live ebuilds should be changed after every minor release, unless we use the number of the next release. Next release isn't always known, and it's doesn't always make sense. This puts us in a worse situation than with GLEP 54, or even with the current use of . components. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
Santiago M. Mola [EMAIL PROTECTED] writes: * media-sound/amarok: live version is 1.4.. Next version is 2.0, but that's a different branch so I'd expect 2.0.live to give me the latest 2.0 version available, not 1.4's. 1.4. has been switched from because of the 2.0/1.4 branches, would be 2.0 (if I ever care enough to add that, not before a beta is released for sure, and not before I can use KDE 4.1 daily, which is not something I expect to happen soonish). Just FYI. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpvaSuTaiUhN.pgp Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: * What generation looks like. * How to select which ebuilds to trigger generation for. * When specifically to trigger generation. * Whether generation failure is possible, and what happens if it is. * What to do when generated information is required but not available. * The security implications of the previous point. * What the impact upon upstream servers is, if any. * How generation fits in with users doing system updates. * How generation fits in with the highly differing frequencies of upstream updates. * How generation can be made to fit in without changes to the version spec, whilst still 'making sense' and doing the right thing. The answers to all of the above are highly non-trivial. Many of them applies as well to the alternative proposal, I wonder how you could say we, council, had to vote the other proposal given such (and other) issues were open. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Santiago M. Mola wrote: On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato [EMAIL PROTECTED] wrote: Ryan Hill wrote: I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... That's an upstream issue, all we should care is about getting a version value that makes sense for us, better if it does for them. I think upstream use release branches correctly here, and it's the most widespread use. There's some real examples where .live = _pre has problems. * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when it's released. MPlayer has a psychological issue with 1.0 versioning, still 1.0.live correctly isn't higher than 1.0 * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse. No, ffmpeg does continuous release every commit must not add regressions and the ABI/API is marked, a correct version for ffmpeg is given by taking the combination of the libraries major version. Every major version update I'll have to update the live ebuild because of that and this is correct. * x11-wm/enlightenment: latest release is 0.16.8.13, current live ebuild is 0.16.. If we use .live here we'd need either 0.16..live (which is quite pointless) or 0.16.8.14.live which would need to be updated after every minor release. 0.17.live is not a possibility at all since 0.17 is a rewrite from scratch and an entire different application. 0.16.9.live sounds that bad? With the current proposal, .live ebuilds should be changed after every minor release, unless we use the number of the next release. You do pick what is good for you. Next release isn't always known, and it's doesn't always make sense. This puts us in a worse situation than with GLEP 54, or even with the current use of . components. I don't see how. Keep in mind that - ebuild should just stay in overlay and shouldn't be used by average users. The should help us developer tracking projects and get us to the point of having a snapshot for common usage. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 14:27:22 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Many of them applies as well to the alternative proposal, I wonder how you could say we, council, had to vote the other proposal given such (and other) issues were open. No they don't. The alternative proposal is deliberately simple enough to avoid those issues, whilst leaving the possibility of a larger solution that does have scm revision awareness open for the future. Does this mean you don't have answers then? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Sat, 14 Jun 2008 14:27:22 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Many of them applies as well to the alternative proposal, I wonder how you could say we, council, had to vote the other proposal given such (and other) issues were open. No they don't. False. Does this mean you don't have answers then? From start I asked for help and from start I said that my proposal is anything but complete. I have no delusion to have all the answers at hand anytime. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 15:15:45 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Sat, 14 Jun 2008 14:27:22 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Many of them applies as well to the alternative proposal, I wonder how you could say we, council, had to vote the other proposal given such (and other) issues were open. No they don't. False. Which of the issues I listed needs to be addressed for the scm proposal? Does this mean you don't have answers then? From start I asked for help and from start I said that my proposal is anything but complete. I have no delusion to have all the answers at hand anytime. Ok, here's the best help I can give you: Your proposal can't work. You can't get correct ordering reusing existing components. You can't get sane behaviour using your template scheme without making it aware of scm revisions. You can't make it scm revision aware without a hell of a lot of work. And if you do want to make it scm revision aware, you need changes to the version scheme anyway. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: * What generation looks like. Mostly implementation detail? Somebody seems to have ideas there and I like to heard ideas from others as well. * How to select which ebuilds to trigger generation for. I'm fond of sets and I'd extend maint to be feeded to sets other than world and all. * When specifically to trigger generation. User decision or triggered by sync depending on a FEATURE. * Whether generation failure is possible, and what happens if it is. I could think easily that such thing could happen (no network is a possibility) * What to do when generated information is required but not available. Consider the ebuild corrupted or do not generate it. * The security implications of the previous point. None? * What the impact upon upstream servers is, if any. Shared with glep 54 * How generation fits in with users doing system updates. Orthogonal * How generation fits in with the highly differing frequencies of upstream updates. Being user driven isn't an issue at all. * How generation can be made to fit in without changes to the version spec, whilst still 'making sense' and doing the right thing. Discussion going on in this thread, so far Coldwind did quite well to pointing actual cases present in portage already, discussion on them should help sorting out issues. Using live sources is a security and stability concern by itself and by accepting that you are at the very end of the bleeding edge you acknowledge that you are experimenting. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 14:01:15 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sat, 14 Jun 2008 14:27:22 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Many of them applies as well to the alternative proposal, I wonder how you could say we, council, had to vote the other proposal given such (and other) issues were open. No they don't. The alternative proposal is deliberately simple enough to avoid those issues, whilst leaving the possibility of a larger solution that does have scm revision awareness open for the future. Just curious, were you happy with the previous GLEP54 draft or were there still issues that had to be addressed? As far as I'm concerned it's fine. (though I would change the suffix to -live, just because i hate the term SCM :P) -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 08:45:08 -0600 Ryan Hill [EMAIL PROTECTED] wrote: Just curious, were you happy with the previous GLEP54 draft or were there still issues that had to be addressed? As far as I'm concerned it's fine. (though I would change the suffix to -live, just because i hate the term SCM :P) I'm happy with GLEP 54 as being the first, easy half of getting proper scm support. It correctly solves the ordering and identification issues. The second, really difficult part is making the package manager aware of upstream scm revisions. That can be done later by building upon GLEP 54. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 12:32:22 + Patrick Lauer [EMAIL PROTECTED] wrote: Ok, here's a silly idea - tag the ebuilds with metadata. We already have RESTRICT, why not add a LIVE variable. The package manager can then treat all ebuilds with that tag differently. Scripts can find them easily. Or we could create a scm suffix and not have to parse ebuilds to get that info. As an added bonus live ebuilds are instantly identifiable and can use proper versions numbers instead of . Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets like the @preserved-rebuild. Shouldn't be that hard to add a live-ebuilds dynamic set. Just as easy with -scm. (Comments on the feasibility of my idea from portage people appreciated) Currently, users with Portage have to run something like: ~ emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \ ~compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \ ~emerald emerald-themes libcompizconfig compizconfig-python \ ~ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \ ~compiz-fusion fusion-icon That is the situation where you really love the sets in portage 2.2 - by default portage will re-merge every ebuild from a set when run as emerge @your-custom-set. Now the overlay maintainer just has to provide the sets with the overlay and users are happy. His problem is updating the packages in a specific order. I don't remember sets preserving merge order, but then again I wasn't looking. Having a method that lets the user choose that the PM should check the scm tree and update the package if there's a new revision would be even better. I think that can be easily done if there's an easy way to pull the installed revision and currently available. The last discussions about that stalled without reaching agreement. I could have sworn subversion.eclass already did this but now I can't find the code. I might have seen it in an overlay or on the forums. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
Ryan Hill [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 14 Jun 2008 09:04:26 -0600: Having a method that lets the user choose that the PM should check the scm tree and update the package if there's a new revision would be even better. I think that can be easily done if there's an easy way to pull the installed revision and currently available. The last discussions about that stalled without reaching agreement. I could have sworn subversion.eclass already did this but now I can't find the code. I might have seen it in an overlay or on the forums. Isn't it subversion itself that does this, based on local and remote repository revision numbers? -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote: So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ You'd like to have the cflags and ldflags embedded in the name for the same reason? If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? You can. The generated ebuild must have a reference to the checkout. If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. The generated ebuild contains pretty much everything you need to fill a bugreport. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Bernd Steinhauser wrote: MPlayer has a psychological issue with 1.0 versioning, still 1.0.live correctly isn't higher than 1.0 No, it is not. For mplayer it is correct. I'm MPlayer upstream as well. I do know. In the -scm approach this means: trunk = -scm 4.1 branch = -4.1-scm so you'll be oblivious of changes needed inside the ebuild and you won't know what you merged last time you issued an emerge =foo-scm (that by itself it is a problem, since it is ambiguous) With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. trunk = .live nope it would resolve as foo_pre1 - meaningless. 4.1 branch = 4.1.1.live (before 4.1.1 has been released) correct, you can keep tracking 4.1.1, have interim snapshot pushed in portage to ~ if you are confident about them. 4.1 branch = 4.1.2.live (before 4.1.2 has been released) 4.1 branch = 4.1.3.live (before 4.1.3 has been released) same reasoning. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 18:03, Luca Barbato wrote: trunk = .live nope it would resolve as foo_pre1 - meaningless. So your proposal is unable to handle that case, right? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: nope it would resolve as foo_pre1 - meaningless. So your proposal is unable to handle that case, right? You are forced to put a version, that's all. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 18:23, Luca Barbato wrote: Fernando J. Pereda wrote: nope it would resolve as foo_pre1 - meaningless. So your proposal is unable to handle that case, right? You are forced to put a version, that's all. Which doesn't always make sense so we are back to 9 versions. I don't consider this an improvement over the current situation. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Luca Barbato schrieb: Bernd Steinhauser wrote: In the -scm approach this means: trunk = -scm 4.1 branch = -4.1-scm so you'll be oblivious of changes needed inside the ebuild and you won't know what you merged last time you issued an emerge =foo-scm (that by itself it is a problem, since it is ambiguous) Huh? What has to do with the ordering? And finding out what I installed last time is trivial and not the point. With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. trunk = .live nope it would resolve as foo_pre1 - meaningless. 4.1 branch = 4.1.1.live (before 4.1.1 has been released) correct, you can keep tracking 4.1.1, have interim snapshot pushed in portage to ~ if you are confident about them. Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. I have got a feeling, that you didn't have to deal with live packages that much yet. (No offense.) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill schrieb: On Sat, 14 Jun 2008 11:53:51 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Sat, 14 Jun 2008 10:19:32 +0200 Luca Barbato [EMAIL PROTECTED] wrote: I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? it would be gcc-4.4.0_pre1 but you'll have the revision inside the ebuild as var so you can get it easily. (e.g. the description shows it) And when would gcc-4.4.0_pre2 become available? It will be available once you trigger again the generation or if you put a normal ebuild with such name. So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. No, the idea behind ESCM_LOGDIR was different. If you just want the revision of the current installed thing, you can grep through the environment. ESCM_LOGDIR mainly aimed to provide a history of revisions you installed. So that you can then tell upstream Hey, I have this revision installed and it doesn't work, but this revision worked.. So it is definitely related, but not the same. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 17:55:27 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ryan Hill wrote: So every user will have a different _preN version which would vary depending on how often they rebuild the package and that has absolutely no correlation with the revision number of the upstream codebase. I'm sorry, but that's unacceptable. :/ You'd like to have the cflags and ldflags embedded in the name for the same reason? There's no need to set up a strawman. I expect that everyone installing a version of a package is building from the same sources. Do you really not see a problem here? Okay, taking a different approach, what does an auto-incrementing suffix gain us? The ability to auto-merge a live ebuild at regular intervals? That's something that can easily be achieved without mucking about mangling CPVs, in any implementation we decide on. What is it about your particular idea that makes it worth the numerous disadvantages that we've pointed out? If a user reports a bug in package-1.1_pre6, how do you determine what revision he has installed? How can you even tell it's an scm ebuild? You can. The generated ebuild must have a reference to the checkout. This is the first time you've mentioned this. Where would you find such information? How would you know that the ebuild the user is using is a generated ebuild, and not just a standard ebuild that happens to end in _pre6? How would that information get into the ebuild? Would it have to come from the various VCS eclasses? What about those that don't have a way of getting at the revision number (like say cvs.eclass)? Would it have to be placed there by the package manager? If so, then we're back to having to implement support for every VCS inside the PM. If I want to report a bug I find to upstream, how to I know what revision I have? Yes there are hacks like ESCM_LOGDIR, but they're different for every SCM and you have to opt-in to use them. Most people don't even know about them. The generated ebuild contains pretty much everything you need to fill a bugreport. Could you please provide an example of a generated ebuild so we can see what kinds of info it contains? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 18:34:21 +0200 Bernd Steinhauser [EMAIL PROTECTED] wrote: Ryan Hill schrieb: No, the idea behind ESCM_LOGDIR was different. If you just want the revision of the current installed thing, you can grep through the environment. ESCM_LOGDIR mainly aimed to provide a history of revisions you installed. So that you can then tell upstream Hey, I have this revision installed and it doesn't work, but this revision worked.. So it is definitely related, but not the same. Well, true. But it does give you the latest version you installed. ;) It was the only example I could think of (and one I use constantly). gcc is nice enough that i can do `gcc -v` and get gcc version 4.3.2-pre20080612 built 20080614 (Gentoo SVN ebuild) rev. 136782 () but not everything works like that. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote:
On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ryan Hill wrote:
So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has
absolutely no correlation with the revision number of the upstream
codebase. I'm sorry, but that's unacceptable. :/
You'd like to have the cflags and ldflags embedded in the name for
the same reason?
There's no need to set up a strawman. I expect that everyone
installing a version of a package is building from the same sources.
Do you really not see a problem here?
Well the idea is to have the revision/reference behave like CFLAGS and
src_uri such variables, sorry if I just said that backwards.
Okay, taking a different approach, what does an auto-incrementing
suffix gain us? The ability to auto-merge a live ebuild at regular
intervals? That's something that can easily be achieved without
mucking about mangling CPVs, in any implementation we decide on. What
is it about your particular idea that makes it worth the numerous
disadvantages that we've pointed out?
I don't see disadvantages, all I wanted is a simple way to archive this:
# emaint -r ffmpeg
# emerge ffmpeg -p
[ebuild U ] media-video/ffmpeg-0.4.9_pre1235 [0.4.9_pre1234] [1]
[1] from ffmpeg-0.4.9.live
# emerge ffmpeg
fails, configure changed
# vim /usr/portage/media-video/ffmpeg-0.4.9.live.ebuild *1*
fix it
# emerge ffmpeg -L
builds as should test suite ok, further tests ok, everything builds
using it.
# egen ffmpeg 0.4.9_p${date} *2*
# scp /usr/portage/distfiles/ffmpeg-0.4.9_p${date}.tar.bz2
dev.gento.org:place
# cp usr/portage/media-video/ffmpeg/ffmpeg-0.4.9_p${date}.ebuild
/var/cvs/gentoo-x86/media-video/ffmpeg/
# cd /var/cvs/gentoo-x86/media-video/ffmpeg/
# cvs add ffmpeg-0.4.9_p${date}.ebuild
# echangelog New revision repoman ci -m New revision
[1] or just ffmpeg-0.4.9.live if you like better.
[2] emaint -g instead of egen
I do not want end users using this stuff.
If a user reports a bug in package-1.1_pre6, how do you determine
what revision he has installed? How can you even tell it's an scm
ebuild?
You can. The generated ebuild must have a reference to the checkout.
This is the first time you've mentioned this.
really? btw s/generated/recorded in the vdb.
Where would you find such information?
from the vcs since on unpack or before I have to have the sources and
thus the revision.
How would you know that the ebuild the user is using is a generated ebuild,
and not just a standard ebuild that happens to end in _pre6?
Being the maintainer I should know what's in the tree. If somebody
happens to use an overlay that shadows the main tree how you'd be able
to tell the difference from foo-1.2.3 and foo-1.2.3?
How would that information get into the ebuild? Would
it have to come from the various VCS eclasses?
Right.
What about those that don't have a way of getting at the revision number (like
say
cvs.eclass)?
A timestamp should do, I cannot think anything better. You want to have
in the recorded ebuild everything useful to replay the process.
Would it have to be placed there by the package manager?
Yes.
If so, then we're back to having to implement support for every VCS
inside the PM.
Having support inside the template to have such information in a
variable you can save (as CFLAGS and friends) doesn't require this =)
If I want to report a bug I find to upstream, how to I know what
revision I have? Yes there are hacks like ESCM_LOGDIR, but they're
different for every SCM and you have to opt-in to use them. Most
people don't even know about them.
The generated ebuild contains pretty much everything you need to fill
a bugreport.
Could you please provide an example of a generated ebuild so we can see
what kinds of info it contains?
I phrased that badly.
we have some phases:
given we have a simple ebuild
Once we get a new template we can trigger a phase that makes the pm
consider the existence of an ebuild alike the current - ones: they
pick the tip of the branch chosen from the repository defined.
But with the version generated as already said.
If such ebuild get chosen for merge it behaves pretty much like the
current ones, but the PM stores additional informations in the vdb
(using current subversion.eclass as example it records the equivalent of
ESVN_REVISION). Such informations let you know how to reproduce the
build and let you generate a static snapshot automatically.
A dirty and simple way to implement this stuff right now (abusing
everything) is to:
have a script that scans the tree for .live templates and generates
ebuild out of them and places them in an overlay
have those ebuild rewrite themselves in the vdb adding the information
needed.
Making it less dirty requires adding a new phase and possibly some new
functions as ciaranm suggested.
--
Luca Barbato
Gentoo Council Member
Re: [gentoo-dev] Re: A few questions to our nominees
Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. If you want to track something you write a template for such thing, you just need to put a meaningful name, portage won't care if foo-0.live is really bar branch baz from repo dup. Advanced testers should be able to pick the live template and help testing and should be able to smoothly update, I'm all for it. I have got a feeling, that you didn't have to deal with live packages that much yet. (No offense.) Beside e17 and ffmpeg you mean? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? (btw they are single packages, emerge =python- works as should) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? (btw they are single packages, emerge =python- works as should) So what was your proposal all about? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Luca Barbato schrieb: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. Wow, impressive. Actually, you can't be serious... Of course I can track 4.1.1 with -scm, too, but that was absolutely not the point and is by far not what I wanted. The point was to track the 4.1 branch and not tags inside. If you want to track something you write a template for such thing, you just need to put a meaningful name, portage won't care if foo-0.live is really bar branch baz from repo dup. Advanced testers should be able to pick the live template and help testing and should be able to smoothly update, I'm all for it. See, the problem here is, that, I have been using -scm as proposed in GLEP 54 for quite some time now and it works very well. I just don't see any benefit from your proposal, on the contrary there are issues. And that includes the ordering. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Ryan Hill wrote: (...I would change the suffix to -live, just because i hate the term SCM :P) ++ on using live and not the scm acronym (no matter which idea is selected), especially since there are various different acronyms for config mgmt (scm, cm...), and scm's meaning is less obvious at first glance. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. No need, emerge @kde-svn will re-merge all packages in the set by default. So unmerging isn't needed and it just works. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Bernd Steinhauser wrote: Wow, impressive. Actually, you can't be serious... I am. GLEP 54 for quite some time now and it works very well. adds nothing to - and sets usage as is. I just don't see any benefit from your proposal, on the contrary there are issues. No. And that includes the ordering. No. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? mainline glibc usually requires you to fix it or the rest of the world... (btw they are single packages, emerge =python- works as should) So what was your proposal all about? Doing something more. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On 14 Jun 2008, at 22:18, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 20:02, Luca Barbato wrote: Fernando J. Pereda wrote: On 14 Jun 2008, at 19:36, Luca Barbato wrote: Bernd Steinhauser wrote: With your approach, we would have to fix the version after every 4.1.x release. That sounds awful, tbh. So: No that enforce people update the deps or at least gives one more reason to do. Keep in mind that -, -scm ebuild or .live templates aren't for public consumption. Except, that it is not that easy. The point of time where you have to update your kde deps has nothing to do with that. This is why we recommend to always reinstall everything from kde svn. It is even more likely, that these problems occur after the bump, that shouldn't have been one at all. emerge -C @kde-svn emerge @kde-svn that should suffice. I don't see that working for something like, say, python or glibc. do you really want to use live ebuild of THOSE? Why not? mainline glibc usually requires you to fix it or the rest of the world... What? (btw they are single packages, emerge =python- works as should) So what was your proposal all about? Doing something more. How is using versions 'doing something more'? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Fernando J. Pereda wrote: On 14 Jun 2008, at 22:18, Luca Barbato wrote: mainline glibc usually requires you to fix it or the rest of the world... What? I experienced that the hard way -_- (btw they are single packages, emerge =python- works as should) So what was your proposal all about? Doing something more. How is using versions 'doing something more'? Using live templates is something more ^^; lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
Using live templates is something more ^^; For now it looks to me like it is only more work. Could you please clarify what new functionality they provide? -- Best Regards, Piotr Jaroszyński
[gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote: On Fri, 13 Jun 2008 10:43:39 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 12 Jun 2008 21:40:28 +0200 Luca Barbato [EMAIL PROTECTED] wrote: * ordering for _pre is wrong. hm? foo-0.26-live would become foo-0.26_pre1, which would be 0.26. This is clearly wrong. No, it is correct and what you want. Upstream is aiming for 0.26, once 0.26 gets in portage you want to update to the release. A lot of projects work like this: * trunk/ is current development, and is ahead of any release. * branches/0.26/ is forked from trunk/ when 0.26 is released, and is equal to or ahead of any 0.26 release. How does your proposal handle this? s/_pre/_p ? -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
Ciaran McCreesh wrote:
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato [EMAIL PROTECTED] wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would be 0.26.
This is clearly wrong.
No, it is correct and what you want. Upstream is aiming for 0.26,
once 0.26 gets in portage you want to update to the release.
A lot of projects work like this:
* trunk/ is current development, and is ahead of any release.
* branches/0.26/ is forked from trunk/ when 0.26 is released, and is
equal to or ahead of any 0.26 release.
How does your proposal handle this?
* How are you planning to handle reinstalls? Should installing
world always reinstall live things? Never? Or what?
depends on the other ebuilds
More specifically?
the live ebuild act as template for a autogenerated _pre, if there is
something higher than _pre that one will be picked.
So you install foo-1.2-live. The package manager installs this as
foo-1.2_pre1. Then, foo-1.2-live becomes foo-1.2_pre2.
Which has two issues:
* It means whenever you install foo-1.2-live, there will always be a
newer version, and the package manager will always select it for
upgrades. Is this really desired behaviour?
* It means the package manager somehow has to keep track of what pre to
substitute in. How does it do this?
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
(Just in case you were thinking of letting the pm auto-masking/unmasking
foo_p${value+1}: this would be hackish and ugly).
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Fri, 13 Jun 2008 11:14:49 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: How does your proposal handle this? s/_pre/_p ? Collides with existing use of _p. It means you can't use _p for manual snapshots if there's also a live ebuild, since foo-1.2_p3 (from a live ebuild) would incorrectly order less than foo-1.2_p20080613 (from a manual snapshot). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A few questions to our nominees
Tiziano Müller wrote:
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
a live ebuild is a template, every time it has to be evaluated it acts
as a normal ebuild with the version mentioned and _preN+1 postponed,
preN is the highest preN present, if present.
(Just in case you were thinking of letting the pm auto-masking/unmasking
foo_p${value+1}: this would be hackish and ugly).
Uh?
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
On Fri, 13 Jun 2008 13:35:52 +0200 Marius Mauch [EMAIL PROTECTED] wrote: Ignoring possible semantic issues for the moment, I'd be against this simply because it would require the PM to be aware of the current revision of the repository and to transform it into a integer value (trivial for SVN, not so trivial for CVS for example). Which in turn either means that the PM has to internally support the SCMs or support some new phase functions to extract the revision. I'm confused. If I have a gcc-4.4.0.live ebuild which checks out rev. 136737, after the merge do I have gcc-4.4.0_pre136737 or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I merge it, etc) installed? The latter would be quite a nightmare. A bug report about an error in package-1.1_pre6 isn't really helpful when everyone's _pre6 is a completely different revision. The former, as Marius said, requires knowledge of how to get a sane revision id from every SCM we want to support to be built into the package manager. I wonder if instead of rev id, we could use a timestamp to fill in _pre. It's not ideal but it narrows the checkout down somewhat. Also, we could use pkg_info to report revision numbers (for those SCM's that have such a thing). The combination of the two might be enough - you'd have the revision you installed, when you installed it, and an automatic incrementor for those ppl who like those kinds of things. * How are you planning to handle reinstalls? Should installing world always reinstall live things? Never? Or what? * How are live ebuilds selected by the package manager? How are reinstalls handled for - ebuilds now? I wouldn't think it would need to change. You'd have to unmask the live ebuild, then it would only be reinstalled if you used --emptytree or specifically asked for it on the command line. I'm not sure this preN+1 thing makes sense. If a user wants to automatically update a live ebuild every week, etc, they need to learn how to use cron. :P If a dev wants to force a reinstall because of ebuild or patch changes or whatever, they should still be able to use -rX as usual. A lot of projects work like this: * trunk/ is current development, and is ahead of any release. * branches/0.26/ is forked from trunk/ when 0.26 is released, and is equal to or ahead of any 0.26 release. How does your proposal handle this? I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... As for an ebuild tracking trunk, I guess we're back to -.live. ;P -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
Peter Weller wrote: On Sun, 2008-06-08 at 13:41 +0100, Alex Howells wrote: [snip] I often don't agree with him, but can't help but respect the work he does. I would like to see Council move towards a more compressed meeting format -- people presenting arguments need to work out their stuff before bringing it up in the meeting, and to allow for quick turn-around of decisions I'd suggest fortnightly meetings which are time-limited to 60 minutes each. A prioritized schedule determines which order we deal with issues in and anything not getting attention is bumped 2 weeks, with the priority adjusted if necessary to ensure it gets attention then. Each issue should be limited to between 5-20 minutes. If people can't get through the politics and debate in the allotted time then it should either get bumped 2 weeks and given another 5-20 minutes, or we should table a special meeting to allow a full 60-90 minutes *just* to decide that one issue and nothing else. Sitting around in #gentoo-council for 3-4 hours every month isn't conducive to progress, it's going to make people get tired/bored and not pay proper attention and/or not bother to turn up, which just leads to elections. Endless cycle? ++ From me on this one. If I were elected to the Council, I would do my best to get this happening. ++ from me too. Along the lines to what I wrote in gentoo.project. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: A few questions to our nominees
Piotr Jaroszy?ski wrote: Hello, looks like every nominee wants the council to be more technical so I have a few technical questions for you: 1. GLEP54 Doit! 2. GLEP55 Good idea. But the GLEP still contains too many may's and should's. Example: [...] but note that one should never explicitly set both EAPIs to different values. [...]. Define it clearer: It is not allowed to set both EAPIs.. And why don't we change the versioning of the EAPI to a X.Y scheme and demand that changes in the minor version must not break sourcing of the ebuild with older package managers and that major versions do. Major version numbers are written in the postfix, while minor version numbers are written in the ebuild itself as EAPI_MINOR=1. So, the current EAPI 1 would then be in fact 0.1. Cheers, Tiziano -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Mon, 09 Jun 2008 09:45:37 +0200 Tiziano Müller [EMAIL PROTECTED] wrote: And why don't we change the versioning of the EAPI to a X.Y scheme and demand that changes in the minor version must not break sourcing of the ebuild with older package managers and that major versions do. Major version numbers are written in the postfix, while minor version numbers are written in the ebuild itself as EAPI_MINOR=1. So, the current EAPI 1 would then be in fact 0.1. No point. A 0 package manager still couldn't use a 0.1 ebuild. -- Ciaran McCreesh signature.asc Description: PGP signature
