Re: [gentoo-dev] rfc: openrc service script dependency checker
Let me state my idea here. At first I want to mention that author provided 2 different approaches to the solution, simple dependency loop checker and another more complicated algorithm that is a loop breaker. I think that on a boot phase in case of parallel boot rc should try to check if loop exists and it is then print a warning and switch to a sequential boot. The only problem here is if its possible to switch to a sequential boot during the boot process. So with this approach we will have a simple solution that will definitely solve the problem, opposed to the loop breaker that afaiu doesn't give such guarantees. A loop breaker can live as a standalone application or as a part of rc-update. Just my 2¢. -- Alexander (qnikst) On Dec 3, 2014 9:39 PM, William Hubbs willi...@gentoo.org wrote: All, we have a pull request on OpenRC for a dependency checker [1]. The author of this patch believes that we should not only scan for circular deps, but break some of them automatically. I, and several other team members I have spoken with on IRC, disagree with this and think that we should just warn about the circular deps since users can break them by modifying files in /etc/conf.d, and the service script writers should be told about these kinds of issues so they can determine whether they neeed to adjust the dependencies in their scripts. I wanted to post a question here to see what people think, so feel free to comment. My opinion is the less automatic adjustment we do the better. Thanks, William [1] https://github.com/openrc/openrc/pull/12
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Dec 3, 2013 1:24 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/13 04:19 PM, Rick Zero_Chaos Farina wrote: On 12/02/2013 03:28 PM, William Hubbs wrote: [...] Also, the other message in this thread is correct; the netifrc use flag is temporary. I originally planned to release openrc-0.12.x along with a newsitem that instructed you to emerge the netifrc package if you want the legacy network stack, but some users/devs felt that Ishould go further to make sure netifrc remains installed on their systems. As one of those devs, I feel now may be a good time to ask What are we doing about this? In my opinion, anyone removing net support from the stage3's should be killed with fire. That said, I don't care if it's netifrc or whatever as long as it is properly documented and actually usable. Thoughts on how we move forward? Thanks, Zero Well, part of this conversation needs to be, what is the default networking stack that we want to have in gentoo? IMO that should remain netifrc but that's just my personal opinion. I personally like netifrc default but there is no good way to use it as default we will need to keep use flag arbitrary long or add netifrc to @system but it will return us back to the problems of users who doesn't want to have netifrc on their systems. And with the rise of systems and NM the number of such users will grow. Anyway I'd like to see base system herd vote. After deciding that, I expect we should decide how to include it. My guess would be, since for whatever reason we don't want netifrc as part of @system or a dep of baselayout-2 or anything like that, we'd need to add it to the special releng include list? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKc+qEACgkQ2ugaI38ACPAu6AD/RpeD8NsMsjt4X5EKYe6Tkixu 6qzCONtd44U+grcxKr0BALw1EaxdI/EQ+Fo3eASssQ8fUH/dRFus5EUPo46dPz0L =Bmfz -END PGP SIGNATURE-
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
The only one unclear case is 4 (+netifrc +newnet) in this case stack that is used is set by enabling required stack by rc-update. Case 3 means that openrc doesn't provide default network stack and it's up to user which stack to use (e.g. NM), so no problem here. Also +netifrc flag is temporal to make update path clean and it may be removed in future. On Dec 1, 2013 2:20 PM, Alessandro DE LAURENZIS just22@gmail.com wrote: I've just upgraded to the latest openrc version; I was aware of the netifrc USE flag introduction (http://www.gossamer-threads.com/lists/gentoo/user/275748). But so far the presence of the newnet flag was actually a switch between the old and the new network stack, given that one of the two should (must?) be added in any case. Now the presence of both netifrc and newnet could make a bit of confusion, particularly from a user perspective. We have of course 4 cases; two of them are clear: 1) netifrc -newnet: legacy network stack; 2) -netifrc newnet: new network stack. The other two cases need a clarification: 3) -netifrc -newnet: no network stack?!? 4) netifrc newnet: ??? This should be definitely documented somewhere (I didn't find anything). And, the last question: what's the point to have two flags instead the good old one? Thanks for any clarification. -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
On 16 June 2013 08:08, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 6/12/13 11:51 PM, Dirkjan Ochtman wrote: Still seems like working in gentoo-x86 without doing stabilization would cover most of those bases. Working in the unstable main tree is still a lot better than keeping stuff out there in an overlay, IMO. +1 This works really well for the Gentoo Chromium team, where we have just hard masked packages and ~arch packages right in the tree. In this is a continuation of a 'gentoo-haskell' sub-thread I have to say that Chromium and co. it not a development library this is a end user application. End user applications should be in tree (except for some testing reasons), if not just ignore this letter. And thanks for your work. -- Alexander
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] Over-reliance of Gentoo projects on overlays
The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. As a part of gentoo-haskell team, I'd like to say that CVS issue is not strongest one, there are much more meaningful reasons for having much stuff in overlays at least for haskell. IMHO: The main point that haskell ecosystem is very breaky and only latest version is supported, so the safest path is to be on a bleeding edge and patch inconsistent applications. So if one package gets updated then commonly we need to fix its reversed deps, if it were in tree than we would be involved into stabilization process and in the end will delay updating deps, and the difficulty of tracking all version variant will be much higher than no, at the end the quality of the packages in tree will fall. Really we can _guarantee_ that everything work in overlay but there is either no technical or bureaucracy reasons that prevent from fixing as soon as possible. All above is applicable because in overlay we work on programmers libraries, with enduser applications (that are synchronized with portage tree) situation is slightly different. -- Alexander
[gentoo-dev] ESCM_OFFLINE/ EVCS_OFFLINE env variable policy
Hello. It seems that in eclasses we have two differenct environment variables with same meaning ESCM and EVCS OFFLINE. Some of eclasses use one and some another: find . -type f | xargs grep -l EVCS_OFFLINE ./git-2.eclass ./bzr.eclass find . -type f | xargs grep -l ESCM_OFFLINE ./darcs.eclass ./cvs.eclass ./mercurial.eclass ./git.eclass ./subversion.eclass It seems we should have some concusion about what env variable should be used to prevent downloading of live repo. Thanks. -- Alexander Vershilov [2048R/5E05C6C2] signature.asc Description: Digital signature
