Re: [gentoo-dev] [RFC] SRC_URI behaviour
2013-06-15 17:51 Rich Freeman napisał(a): Plus, right now with Gentoo there is no way to set an overlay as being LOWER priority than the main tree - so that you can grab packages not supported in main from an overlay but still use the main packages when available. Portage has been supporting setting of priority in /etc/portage/repos.conf for about 2.7 years. $ cat /etc/portage/repos.conf [name_of_overlay] priority = -1001 (`emerge --info -v` shows repositories with their priorities.) -- Arfrever Frehtes Taifersar Arahesis
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/16/2013 02:24 AM, Zac Medico wrote: How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). Sounds interesting. Still please notice that the initial and misdelivered point about live ebuild being NOT for everybody beside who develops software should be clear. lu
Re: [gentoo-dev] [RFC] SRC_URI behaviour
2013/6/16 Zac Medico zmed...@gentoo.org: How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). As a side note from a developer of an app that keeps various loosely coupled modules in one repo — it'd be great if there would be a way to also tell whether the changed revision actually affects the given package. The default, of course, should be to assume that every change in the repo affects a given package, but when it can be proved that package doesn't need to be rebuilt — why bother rebuilding it? Of course, the task of the proof lies on exact ebuild maintainer. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] [RFC] SRC_URI behaviour
I'd like that behaviour! 16.06.2013 07:24, Zac Medico пишет: How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 08:24 PM, Zac Medico wrote: On 06/15/2013 06:05 AM, Michał Górny wrote: Dnia 2013-06-15, o godz. 15:56:53 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo It simply can't work. Don't even try to implement, it's waste of time. Just grep the tree, see how various packages use VCS-es. There's too many differences, too many needs and -- most importantly -- VCS-es change over time much more quickly than, say, unpackers. Even *if* we get a SRC_URI VCS support that works for all consumers, and that'd be awfully hard to do properly, it will eventually stop being 'good enough' and require further changes. It will just become never-ending story for a minor benefit. How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 +1 on src_fetch in or out of the context of this thread. +1 on more granular fetch/mirror restrictions +-0 on VCS in SRC_URI, as I already stated I'm fine with the current functionality (aside from a vast desire for src_fetch phase). - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvc4cAAoJEKXdFCfdEflK990P/267Ej2p26SvRGItzFHtHakH EwDEQcLxfykfqs1p1AWjR2O9e7ZvW7PaF9EyFdypY0MxAu0faB24ek4OKGD4842L VbkQFXRjSOu1e+bLvQERofiVJ2/qSJZmg/phBsLwQiT0GVTm6ZXykZHSjfyTSALG 6ip+bhwUnYGGmxs8oudb7abBy7HfqhFlA6GTnyonqeRXre4QxfWFi1Yup/mRFuWp XFwEoBe9t/95DBiXfjbvO5b6rlVEsChXuxELDUgP1dTdXTYKVRohs0lU6uZqlJkz RY+8p8bJDsZas0Ucw7+7ePb93mH+XCKz5bvMrz2YhEM//NTOC6QY9+F6iy/NevTp FNJeBCYUNKPpGzy4bm1649vDCqG51WK9iG8qtYO5G0y2QpkGZugUfALwalXK7L3M eThjhlGrn0LZvGXxkYNtHgimFg3VWDJXJLHipMkP5dUqC5t4HEaEqgdGTCpzwuka IUAahKdFLd3EZBlc3MHkYwuzfa0/MayOFiMcHKVV2+ONa5FcwkO8Rg6QJk5Xb7A1 NpPU87VampYERtaNcJKVACl8wR8Pltg4Y5xyz5Dgs+ga/gLvun6VePPO3WvKrAsS UirS6VqysSEFaZTFotW0LAN6N8+Mll90gjRRgJxaQcGy1IiZ7VXYGzb8Q9nRWL9n 1PD6mk8hNr9C3aV14QzM =7DTn -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.namewrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo Over my dead CVS access. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 7:50 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo Over my dead CVS access. Grandstanding aside, it is probably best to take this in chunks. The all-or-nothing fetch restriction control does seem like a good place to start improving. I could certainly see where that could create needless problems. It just hasn't been much of an issue because fetch restriction is rare. Mirror restriction is likely a bigger problem even if it is somewhat user-invisible. Do we really want to hammer something like dev.gentoo.org for patches that aren't properly mirrored because the original source cannot be? Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 1:12 PM, Rich Freeman ri...@gentoo.org wrote: Grandstanding aside, it is probably best to take this in chunks. I just don't care to repeat for the Nth time the same reasoning for which I don't want to mainstream VCS fetching. It's just not going to happen as long as I got CVS access, it's not a threat or a grandstanding, it's a simple boolean logic statement. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
15.06.2013 18:50, Diego Elio Pettenò пишет: Over my dead CVS access. Any reasonable/argumented objection? And, anyway, quoted part is optional behaviour that should just make ebuild-writing easy. Mandatory part is to be able to have restrict://foo.bar and downloadable things at the same time. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15 June 2013 15:50, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo Over my dead CVS access. Can you elaborate: do you object both proposals (about partial restrict and VCS-support) or only second one (VCS-support)? It seems that there were no technical discussions about first one and it seems quite reasonable. -- Alexander
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 13:48, Alexander V Vershilov wrote: Can you elaborate: do you object both proposals (about partial restrict and VCS-support) or only second one (VCS-support)? As I already said in my answer to Rich, the VCS support is XOR'd with my CVS access. And I've already spent too much time on it again, so don't expect further mail from me on the topic. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
Dnia 2013-06-15, o godz. 15:56:53 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo It simply can't work. Don't even try to implement, it's waste of time. Just grep the tree, see how various packages use VCS-es. There's too many differences, too many needs and -- most importantly -- VCS-es change over time much more quickly than, say, unpackers. Even *if* we get a SRC_URI VCS support that works for all consumers, and that'd be awfully hard to do properly, it will eventually stop being 'good enough' and require further changes. It will just become never-ending story for a minor benefit. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 8:14 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: It's just not going to happen as long as I got CVS access, it's not a threat or a grandstanding, it's a simple boolean logic statement. That IS grandstanding. I'm not saying I disagree with the position you advocate, but saying do it my way or I'll quit is basically saying that reasoning besides the community has to add to the balance of the choice their desire to have your contributions. At work just about every boss I have had any respect for would have fired me on the spot for making such a statement and not retracting it (regardless of whether they ended up making the decision I was advocating for). They'd have been right to do so - the cost to an organization of tolerating such behavior is higher than the benefits any individual can offer. It is possible to agree with your argument and fault your communication style at the same time. Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
15.06.2013 20:05, Michał Górny пишет: It simply can't work. Don't even try to implement, it's waste of time. As I already metioned to Diego — VCS part is just optional example of that things, that can be useful. Mainly idea in partial restricting. And I suggest you all (including Diego) to discuss about that, instead of oppositing vcs-related SRC_URI ;) Actually, I've some more words to protect VCS links in SRC_URIs, but I'd be quiet on that, untill discussion will go in right way ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:06, Rich Freeman wrote: At work just about every boss I have had any respect for would have fired me on the spot for making such a statement and not retracting it At work you're also paid to for the time you spend justifying for the Nth time why a proposal is completely crazy and something that no sane people would accept. Nobody pays me to waste my time in explaining *again* why VCS ebuilds should be a corner case and not something to spend time making easier to create (because that's what it boils down to). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:11, Vadim A. Misbakh-Soloviov wrote: And I suggest you all (including Diego) to discuss about that, instead of oppositing vcs-related SRC_URI ;) Then next time don't collapse two widely different proposals, especially considering that one of the two has been already discussed to death. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
Am Samstag, 15. Juni 2013, 15:15:57 schrieb Diego Elio Pettenò: On 15/06/2013 14:06, Rich Freeman wrote: At work just about every boss I have had any respect for would have fired me on the spot for making such a statement and not retracting it At work you're also paid to for the time you spend justifying for the Nth time why a proposal is completely crazy and something that no sane people would accept. Nobody pays me to waste my time in explaining *again* why VCS ebuilds should be a corner case and not something to spend time making easier to create (because that's what it boils down to). How about a blog link or a pointer to an old thread instead? -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, 15 Jun 2013, Rich Freeman wrote: Over my dead CVS access. Grandstanding aside, it is probably best to take this in chunks. The all-or-nothing fetch restriction control does seem like a good place to start improving. I could certainly see where that could create needless problems. It just hasn't been much of an issue because fetch restriction is rare. Mirror restriction is likely a bigger problem even if it is somewhat user-invisible. Do we really want to hammer something like dev.gentoo.org for patches that aren't properly mirrored because the original source cannot be? Trying to get this thread back on track: This part was already proposed in bug 371413. I guess the main problem is to come up with a good syntax for SRC_URI or RESTRICT. restrict+http: (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. Ulrich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:34, Ulrich Mueller wrote: restrict+http: (as suggested by the OP) is probably not enough because it doesn't distinguish between fetch and mirror restriction. nofetch+http and nomirror+http ? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, 15 Jun 2013, Diego Elio Pettenò wrote:
restrict+http: (as suggested by the OP) is probably not enough
because it doesn't distinguish between fetch and mirror
restriction.
nofetch+http and nomirror+http ?
Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT
apply to all of SRC_URI (as it is now) and use the new syntax to
specify any exceptions from the restriction.
Ulrich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 02:34 PM, Vadim A. Misbakh-Soloviov wrote: 15.06.2013 18:50, Diego Elio Pettenò пишет: Over my dead CVS access. Any reasonable/argumented objection? to put in different words: We do not want to use untraceable/transient/ephemeral sources for main ebuilds, live ebuilds are corner cases. Ruby related stuff had it worst regarding mis-packaging and total reliance on git with horrid stories they might tell you later over a large coffee. And, anyway, quoted part is optional behaviour that should just make ebuild-writing easy. Mandatory part is to be able to have restrict://foo.bar and downloadable things at the same time. In fact the restrict part got some proposals and not a terse and stern reject. lu
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 14:47, Ulrich Mueller wrote:
Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT
apply to all of SRC_URI (as it is now) and use the new syntax to
specify any exceptions from the restriction.
WFM
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
El sáb, 15-06-2013 a las 12:50 +0100, Diego Elio Pettenò escribió: On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo Over my dead CVS access. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ Could you please reply with some reasoning instead of that kind of reply? At least for me, it seems pretty authoritative :/ Thanks a lot
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 04:56 AM, Vadim A. Misbakh-Soloviov wrote: Sometimes I find myself in a situation, when I need to use both RESTRICT=fetch for the main distfile and allow fetch for additional ones (langpacks, extensions and so on). Sometimes it is even impossible to split that additions into separate package, since they might want to replace some file (for example, Dear Esther's translations). So, in that case, I think, it'd be useful to change SRC_URI behaviour a bit: for example: SRC_URI= restrict://dearesther-linux-06082013-bin #fetch restrict linguas_ru? ( http://www.dear-esther.com/translations/DE_Russian.rar ) linguas_hu? ( http://www.dear-esther.com/translations/DE_Hungarian.rar ) linguas_hu2? ( http://www.dear-esther.com/translations/DE_Hungarian2.rar ) Alternatively it can be even: SRC_URI= restrict+http://foo.bar/moo-123.run # mirror-restrict or specifying a link for fetch-restrict (like for oracle-jdk) I think something like this would be extremely valuable. Sometimes one file is fetch restricted and the rest are not and we currently don't handle that at all. If you want to write an implementation for it, I think it's great. And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo And it can also be extendable: SRC_URI= hg+http://prosody.im/trunk modules? ( hg+https://prosody-modules.googlecode.com/hg ) I don't quite agree with Over my dead CVS access but yeah, this isn't really a great idea or needed. The current way to fetch live things is both functional and simple enough to be in very wide use. There is currently no need for improvement in my eyes, and I'm not sure this could be considered improvement anyway. Thanks, Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvIR6AAoJEKXdFCfdEflKns8QAJq4N0VDwoLTda5ptmEXhrH9 O6CBNAvz+f4cG/lA9bKRxqjWfce44KQbSCO/nieabLLNTNEtNn+xbdz5AHGJxEKa muxJNhHiUNjqN6J9IyXNqlpV1hC0mrxroN9hTL7HnryJKzLXx7t+IIpnjyFZDdho bw9PH1boAt7YN4FRctoV3ALAXU3zY+v/rJNAoDAwfajteZRipRPEnfGEVeuKjm7o 8PY39eBGmgKzQLoz67RTVVgNwOnsyHeJWJX8XWXaURK/2Lh/jBOdSP23xgh50K20 e4zDdRYHP6YH0vFraIjo9d17NtuuzI3SW78BL8JMHdNbQl7XY5khN/Z/KuKy3ydH ccQba25Snkuz0tL+DBnpMb5JkLz02Jup2ug6VqTPwCTtCykRvDF9jf0JLEcNfEd2 8Tkqn4Jah5+zqYox0xIxlJmwLvnlH8Jc7OLuZEIEjt4x3tEXf8mDSSpWV90aI+A2 7dHi9ealEPAPTdt7LqHuJ6ic7akPH4o/lTE+Yp/OcSIUrAfWThxiLUkgD3vbBh/E ZzQFuIqrtptXWP8jGhw01bcqRp6MfOSuCe5G6pEdR0N8Ud5qnyZyPWeMf/1hUxMy g4RMge28KDscnQy+Z0D0BNGSyYuru5mP+vLnfqKHnUjNzxSSbIXj3F98nXykhVvQ SyGs/KBmBdtLVGqrqVWl =gBw2 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, 2013-06-15 at 15:05 +0200, Michał Górny wrote: Dnia 2013-06-15, o godz. 15:56:53 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo It simply can't work. Don't even try to implement, it's waste of time. Just grep the tree, see how various packages use VCS-es. There's too many differences, too many needs and -- most importantly -- VCS-es change over time much more quickly than, say, unpackers. Well, there is an app in gentoo that can already handle every VCS type. It could easily be modified to handle the above syntax. The portage mods would also not be difficult to interface to it. The BAD!!! part is that it would require even more time for portage to sort out the VCS deps that would need to be added to it's dep calculations after checking the SRC_URI. GOD!, it's already getting slower than it was many years ago before Brian's pkgcore optimizations began to be applied. Not to mention GB's of memory and multiple cores now available that wasn't those many years ago... The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with portage... Even *if* we get a SRC_URI VCS support that works for all consumers, and that'd be awfully hard to do properly, it will eventually stop being 'good enough' and require further changes. It will just become never-ending story for a minor benefit. also, agreed
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with portage... Honestly, native support for overlays is something paludis gets right - the main tree is just another tree and you prioritize them. What I don't like about paludis is that it exposes a lot of implementation details in its config files that are probably best defaulted away (unless that has changed), but having /etc/portage/repositories.d with a bunch of files that each contain a URI and a priority and maybe other optional parameters would be nice. Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 05:33 PM, Rich Freeman wrote: On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with portage... Honestly, native support for overlays is something paludis gets right - the main tree is just another tree and you prioritize them. Not sure it is a great idea in practice. lu
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, Jun 15, 2013 at 11:43 AM, Luca Barbato lu_z...@gentoo.org wrote: On 06/15/2013 05:33 PM, Rich Freeman wrote: On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with portage... Honestly, native support for overlays is something paludis gets right - the main tree is just another tree and you prioritize them. Not sure it is a great idea in practice. This is how virtually all other distros operate - they ship with a list of repositories and the user controls which ones are in use. All such a change would do is make it easier to manage overlays - you'd certainly not be required to use them. Plus, right now with Gentoo there is no way to set an overlay as being LOWER priority than the main tree - so that you can grab packages not supported in main from an overlay but still use the main packages when available. That is, unless you set up the overlay as your main tree and set up portage as an overlay. The approach paludis uses just seems simpler all-around, minus the fact that it doesn't provide defaults for internals that need not be exposed (vdb and such - which admittedly aren't needed by exherbo). Rich
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, 15 Jun 2013 15:56:53 +0700 Vadim A. Misbakh-Soloviov m...@mva.name wrote: Sometimes I find myself in a situation, when I need to use both RESTRICT=fetch for the main distfile and allow fetch for additional ones (langpacks, extensions and so on). Sometimes it is even impossible to split that additions into separate package, since they might want to replace some file (for example, Dear Esther's translations). So, in that case, I think, it'd be useful to change SRC_URI behaviour a bit: for example: SRC_URI= restrict://dearesther-linux-06082013-bin #fetch restrict linguas_ru? ( http://www.dear-esther.com/translations/DE_Russian.rar ) linguas_hu? ( http://www.dear-esther.com/translations/DE_Hungarian.rar ) linguas_hu2? ( http://www.dear-esther.com/translations/DE_Hungarian2.rar ) Alternatively it can be even: SRC_URI= restrict+http://foo.bar/moo-123.run # mirror-restrict or specifying a link for fetch-restrict (like for oracle-jdk) Syntax-wise, one of the proposals for dealing with the explosion of *DEPEND variables is a single variable plus labels. The same syntax could be used here, so you'd do: SRC_URI=http://blah/blah restrict: http://blah/other; and so on, with the usual parentheses for restricting scope of labels. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On Sat, 15 Jun 2013 11:51:03 -0400 Rich Freeman ri...@gentoo.org wrote: The approach paludis uses just seems simpler all-around, minus the fact that it doesn't provide defaults for internals that need not be exposed (vdb and such - which admittedly aren't needed by exherbo). I've not heard people ask for defaults like that before. Most people, when configuring, get these files created automatically for them anyway, and they're useful to have around so you know what to tweak. *shrug* It would be trivial to do a per-distribution default config that gets overridden. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 11:43 AM, Luca Barbato wrote: On 06/15/2013 05:33 PM, Rich Freeman wrote: On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec dol...@gentoo.org wrote: The other thing is that would put a mandatory system requirement on layman which many of the devs would be opposed to. But, there is an open bug calling for it to be merged with portage... Honestly, native support for overlays is something paludis gets right - the main tree is just another tree and you prioritize them. Not sure it is a great idea in practice. lu There was a period where Zorry and I were working on the hardened toolchain off the hardened-dev overlay. Migrating it back to the tree was a pita. Unless the stuff in the overlay is orthogonal to the main tree, you will effectively be creating forks which are not easily merged. Repositories in other distros (eg debian) normally just add new .debs. They don't override deeper structures such as toolchains and core utilities. We can overrride *anything* in the portage tree like eclasses making overlays a more serious matter. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 02:14 PM, Diego Elio Pettenò wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 22:15, Michael Weber wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. You know what? I really should just leave and see how people who think that a live ebild is a nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 22:17, Diego Elio Pettenò wrote: You know what? I really should just leave and see how people who think that a live ebild is a nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. Oh wait, I already know how that's going to happen.. bug #443448 is a nice example. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 11:17 PM, Diego Elio Pettenò wrote: On 15/06/2013 22:15, Michael Weber wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. You know what? I really should just leave and see how people who think that a live ebild is a nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. Fine, we would all benefit from a environment without your snappy comments and cryptic responses. Seriously, learn some social skill in your free time. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15 June 2013 22:21, Michael Weber x...@gentoo.org wrote: On 06/15/2013 11:17 PM, Diego Elio Pettenò wrote: On 15/06/2013 22:15, Michael Weber wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. You know what? I really should just leave and see how people who think that a live ebild is a nice idea will ruin it. It's not like I depend on Gentoo for my work anymore. Fine, we would all benefit from a environment without your snappy comments and cryptic responses. Seriously, learn some social skill in your free time. Please both of you. Stop it now and take it elsewhere. Consider this a friendly warning. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 15/06/2013 22:21, Michael Weber wrote: Fine, we would all benefit from a environment without your snappy comments and cryptic responses. Seriously, learn some social skill in your free time. See, I cannot exactly voice what my opinion of you is on a public forum, or I would have done so. Maybe you should think twice about what _you_ have been doing, rather than worrying about my social skills. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/15/2013 05:12 PM, Rick Zero_Chaos Farina wrote: There is currently no need for improvement in my eyes, and I'm not sure this could be considered improvement anyway. i.e. git-2.eclass provides support for environment override (and variables) for branches, commits and repos, for example EGIT_REPO_URI=some other fancy git clone Hard to cover/encode this functionality in your proposed urls. These look - by the way - a lot like the new packer-4.something git url in Archlinux/AUR. our VCS eclasses should still be superior in functionality. ++ for global RESTRICT=fetch|mirror with overrides in both ways on per url basis as prefix to the protocol, like nomirror+http:// and fetch+git:// . But this needs tivial (?) adaption in every VCS eclass. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlG83TcACgkQknrdDGLu8JAq/wEAmUQkeQaLY8FVGZpO9YNShR43 DQ4hrgT1TNSnUQcwzZQBAImK9nurCVcUn4LJSBD0mtCQah2VVo1VfTUzeoMJs1Tt =B9vk -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 11:24 PM, Markos Chandras wrote: Please both of you. Stop it now and take it elsewhere. Consider this a friendly warning. Agreed. Sorry for my impulsive response. I don't say thanks for the warning, but for your counseling of the mailing list. I'm on a borderline between advocation against abusive or destructive behavior leeding to the last two retirements and just leaving these people. I hate the overlay/fork symptomatic, and I have put a lot of effort into making Gentoo into my personal understanding of Linux, but i'm considering stepping down to a overlay basis and avoid all the bitching and alpha-male stupidity. Bye, Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] [RFC] SRC_URI behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/2013 05:15 PM, Michael Weber wrote: On 06/15/2013 02:14 PM, Diego Elio Pettenò wrote: It's just not going to happen as long as I got CVS access, it's not a?T threat or a grandstanding, it's a simple boolean logic statement. Step away then. Okay now we are grandstanding the grandstanding. Please, let's keep to technical issues and not intentionally antagonize people. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvOz1AAoJEKXdFCfdEflK3UEP/i/Y+LCRRkZ3w6D+45BVhmVr VDpEiTZMt1DhJpm/Wu9eYwyfB/dVDHu027KNRWlyrPnBA/nwo0KqYR8lnqZFVcvS mLXf5dIy0MarVO1AsbyOFpbkSfujhlZwFLOl7lCk2fh/biPVdMjaSnOoP9K1Ii0X mhrh2B84kSgRgsLonp1pMdtP4u+jnpMxA82UOxe62tzw04WroOh1BZsc7opQM3t/ ex7td5lfkQJv8kH03+GoxhV1svORo9zoXpbQtvPGvYDBOGY2l/6kmDMCOOZKVl9A h1xC4VGUPElp6h88lHkMXOfR6RazdXt380e/vXwONdc3ciaG1Z/ilNAVv1DLZTFD rowXf0imuo9INCwsTPYPwWYP/wfHfZ3TMPkhz7j9BV7mJqkfbvpI6uPU5CJNQNls I79N0RBWp+oeMVF9CXee2s7JEmwOAvsMPPTpe0fI/UHJntnEBTWdCOlnfyFK2C/9 9/BlI3Jnc6y/bDCzleavEEWql7ZDDUac6JBC3hl29lbqrIulLk5HzI7FgfP/8x+/ 6482AeNlpE/xPXuTiwEK0NWeHtbECzqA8u2XA3EGFzEQ9bZQ0xxojH+Z+XZW6ak0 Na6ShPu3P0PNH0PYCazgS5kfyvpoS0fXpPyfO1UVNpGi4bQx1DjKBlgWstdrgh7b PKVCPTD/xh/ia6qHzbjM =EP39 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] SRC_URI behaviour
On 06/15/2013 06:05 AM, Michał Górny wrote: Dnia 2013-06-15, o godz. 15:56:53 Vadim A. Misbakh-Soloviov m...@mva.name napisał(a): And, moreover, I guess, SRC_URI can even be used for VCS: SRC_URI= git+ssh://github.com/lol/moo.git hg+ssh://bitbucket.org/lol/moo svn+ssh://assembla.com/lol/moo It simply can't work. Don't even try to implement, it's waste of time. Just grep the tree, see how various packages use VCS-es. There's too many differences, too many needs and -- most importantly -- VCS-es change over time much more quickly than, say, unpackers. Even *if* we get a SRC_URI VCS support that works for all consumers, and that'd be awfully hard to do properly, it will eventually stop being 'good enough' and require further changes. It will just become never-ending story for a minor benefit. How about it we add a src_fetch phase, so that the VCS intricacies can be delegated to ebuilds/eclasses (like they are now, but without having to abuse src_unpack). If we include a way for src_fetch to communicate changes in VCS revisions to the package manager, then we'll be able to integrate functionality like smart-live-rebuild directly into the package manager (as discussed in bug 182028 [1]). [1] http://bugs.gentoo.org/show_bug.cgi?id=182028 -- Thanks, Zac
