Re: [gentoo-dev] [EMAIL PROTECTED]
Ciaran McCreesh wrote: Mike Auty <[EMAIL PROTECTED]> wrote: I'm quite happy to continue working in a friendly helpful environment, where simple questions are most often met with patient answers and people are given the chance to learn, improve and help out where they can. I'm happy to keep quietly maintaining my ebuilds and let the people whose packages I package come up with the new stuff. You don't seem to be, so perhaps this isn't the right place for you to contribute? ~ If you do want to contribute, perhaps you could consider the environment you're working in, and be more accommodating to it rather than fighting against it? The environment is a large part of Gentoo's problem. The focus needs to be taken away from the 'community' (where community means a bunch of Ubuntu users who make lots of noise on the forums) and put back into delivering a decent distribution. But people will never agree on where to draw that line. While Mike wants "a friendly helpful environment, where simple questions are most often met with patient answers and people are given the chance to learn, improve and help out where they can", you want everybody to be 100% proficient. Now, here's the point: if only those people ever spoke who are 100% sure that they're 100% proficient, there would probably be only 1-2 people left to discuss an issue. That is not just shutting out "a bunch of Ubuntu users who make lots of noise on the forums" (I don't think that's an adequate definition for 'community', btw), but also lots of experienced users and actually most of Gentoo's developers. Additionally, you can have such a discussion in private. You say you're trying to improve Gentoo. Fine. You say you want to do this fast. Fine as well. But you have to realize that fast won't work without support from your user base. After all, most Gentoo users aren't here to just to use the great package manager. They want to understand their system. (If they didn't, they were off to use Ubuntu/... anyway.) But now here you come, saying "Great new feature, has to be that way, won't explain to all of you uninformed people." I don't want you to explain every bit. But if someone raises a concern or has a question (and I expect him to have thought about what he's saying before doing so), you just continue acting like that. So, how can you possibly expect any support? -- Thomas Pani -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] rfc: Accessibility on our release media
On Sun, May 24, 2009 at 1:14 AM, Andrew Gaffney wrote: > The real issue here is the size. If these additional packages plus all of > the alsa modules add 20MB to the minimal CD, it's just not worth it. It's > not "minimal" anymore. > Could you elaborate whom that change would affect (negatively)? 83MB for current x86 isn't really "minimal" any more, anyway. I don't see the difference between 83MB and 103MB: - Makes no difference on blank CD (even those minis have ~200MB). - Regarding download size, well, after the CD you'll have to get the stage tarball and most probably source tarballs as well. -- Thomas Pani
[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Here's why I think you can't -- or at least shouldn't -- put EAPI into the filename. >From your EAPI definition: > A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the > cat/pkg-ver as a whole, and is static across that cat/pkg-ver. It's clearly NOT the purpose of a filename to describe how the contents of a file are structured/formatted/encoded/etc. It's sole purpose is to uniquely identify a file. Example: I use .txt to identify my text documents. However, I don't use .txt-utf-8, .txt-latin-1, .txt-iso-8859-15 just because their encoding differs. As cat/pkg-ver ultimately is ONE file in the filesystem, there's no reason to put any information about the EAPI in the filename. I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and the last 500 comments lack to explain that. Ebuilds are bash. EAPI=xxx is bash syntax. If you just don't like EAPI being defined as variable (because future EAPIs could define that EAPI is assigned via a function), there are other ways to put this into the ebuild. Eg. Python PEP 0263 ([1]) proposes a way to declare the encoding inside of the source file. Same could be done for the EAPI. Or just write a GLEP that states EAPI has to be assigned via the EAPI variable. You're trying to *set* a standard here, so act accordingly. thomas [1] http://www.python.org/dev/peps/pep-0263/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Thu, 20 Dec 2007 11:37:01 +0100 > Thomas Pani <[EMAIL PROTECTED]> wrote: >> As cat/pkg-ver ultimately is ONE file in the filesystem, there's no >> reason to put any information about the EAPI in the filename. > > Sure there is. It's the sanest place to put it such that it's available > when it's needed -- that is, before the ebuild is sourced. > >> I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and >> the last 500 comments lack to explain that. Ebuilds are bash. >> EAPI=xxx is bash syntax. > > Uh, I've explained it far too many times in this thread already. Go > back and read. Don't post again until you understand it. > I DO understand. You say that explicitly having EAPI=xxx in the first non-comment line / in the ebuild header / whereever imposes restrictions on the ebuild format itself that go beyond "it has to be bash". That's right. But you're totally ignoring my point. So once again: You're trying to *SET* a standard here. There are lots of people telling you that they're not happy with the proposal to change the ebuild filename suffix. There seem to be less people opposed to having that ebuild format restriction. So either choose the one that's accepted by the majority (and I'm not saying that EAPI=xxx is the one; I'm saying that we'll have to figure that out), or think of something completely new. Thomas Pani -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Wulf C. Krueger wrote: >> I DO understand. > > You don't. The complete paragraph of yours shows you don't. > Interesting, because my statement is the same (in meaning) that Ciaran made two days ago. He stated it was "[...] another option. It's considered less ideal [...]" ([1], in case you want to look it up) >> But you're totally ignoring my point. So once again: You're trying to >> *SET* a standard here. There are lots of people telling you that they're >> not happy with the proposal to change the ebuild filename suffix. > > Yes, indeed. They're not happy with it. That's about all most > participants here have stated so far. There are two or three valid > *technical* concerns and all the rest is basically noise. > My concern is technical: Filenames are for identifying files uniquely. An ebuild is uniquely identified by /-, so that's what it's filename should be. Adding anything else to the filename will only clutter the tree and lead to additional inconsitencies. Yes, you can check for these using QA tools. But if it's not in the filename you don't have to check. If you say that package managers need the EAPI info so early that they can't even read the first non-comment line of an ebuild that's fine. Go and place it in the filename. But nobody had a *technical* argument why that's the only possible solution so far. All I got was "you don't understand all that fancy PM stuff". >> There seem to be less people opposed to having that ebuild format >> restriction. > > If this was only about the ebuild format restriction, I wouldn't even > bother to write a single mail on this subject. It's much more important > than that - the suggested GLEP would allow us to make use of new EAPI > features much earlier than now and without causing major problems, I think. > > Just this morning when I was reading my backlog in #-dev, I saw a > discussion between between two devs that culminated in the following: > > a> "So we can make use of this feature in about a year?" > b> "Yeah." > > Are we Debian now? A new feature gets implemented (obviously because we > *need* it) and we can make use of it in a *year*? > No, we're not Debian, thank god. I thought the "wait 1+ year" policy changed? Again citing Ciaran: "That was only the case because previously, using new features that Portage didn't support would cause horrible breakage. Now, instead, the ebuilds show up as being masked." [2] Regards, thomas [1] http://archives.gentoo.org/gentoo-dev/msg_149455.xml [2] http://archives.gentoo.org/gentoo-dev/msg_149031.xml -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 10:59:14 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> And file extension like welcome.html.fr is quite self-explanatory. >> But an total outsider has no chance to deduce what the 1 in ebuild-1 >> means on his own. > > A total outsider doesn't need to know. The only people who will be > dealing with .ebuild-* files are developers and power users. > And you are trying to set an even higher barrier for people to reach that level. How many power users or devs do actually care/know what EAPI=1 means? Regards, thomas -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] OpenRC available for testing.
Works fine here (x86). Having set both RC_{QUIET,VERBOSE}="no" it's a
little more verbose than what I'm used to (especially udev loading
madwifi) but that's early enough in the boot sequence not to bug me.
It took me some time to find /etc/conf.d/modules, but it's certainly
useful :).
Regards,
thomas
Roy Marples wrote:
> I'd appreciate a lot of testing, and just email this thread or me saying
> that it works or there's a bug. Hopefully we can get this into portage
> soonish.
>
--
[EMAIL PROTECTED] mailing list
