Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote: > On Mon, Mar 12, 2012 at 05:12:28PM +, Ciaran McCreesh wrote > > > This whole thing is just an exercise in trying to find excuses not to > > use GLEP 55. > > A filename should not be (ab)used as a database. The main argument for > GLEP 55 is that it would make ebuild-processing generic. I.e. making > ebuild info available to whatever future ebuild processor replacement > for bash was used. A couple of comments... > > 1) Let's talk generic. Right now, we're talking about EAPI. In future, > what other (meta)data and characteristics will we need to know? What > else will be tacked onto the filename? EAPI, and any other critical > (meta)data should be declared early on in the ebuild. That's what the > ebuild is for. > > 2) Any potential ebuild processor that's incapable of looking for regex > "^EAPI=" in a textfile, amd parsing the numbers that follow, has no > business being used to process ebuilds. Perfectly valid, if stupid, bash: EAPI=3 EAPI=4 Which is the PM to choose? Because if your answer is "the first", then you need to keep in mind that any following code (including eclasses that test eapi) will be seeing the second during sourcing. Nice little gotcha, that one. I'm aware people have suggested "make EAPI readonly" to try and deal w/ this; that however means it'll break any PM that uses eval for loading the ebuild, and means that every ebuild sourcing for phase running will throw a complaint about EAPI being readonly. I don't hugely expect PMs to screw up the ordering of which to chose, although it exists; trying to ban secondary settings is also an approach... but all of it points to the fact it's a fricking hack and isn't really worth doing. If we're going to redo EAPI, redo it right. Don't half ass it- this time around we're not forced to make compromises. Viewing it that way, this grep hack shouldn't be on the table as a viable option. ~harring
[gentoo-dev] Re: RFD : .ebuild is only bash
Kent Fredric posted on Tue, 13 Mar 2012 18:14:23 +1300 as excerpted: > Eh? How? If you make "." a forbidden character in an eapi > specificiation, > and make "." the delimiter > > dev-foo/foo-bar-2.3.4.eapi5.eb > > > > How does that require regex? > > remove the .eb , and the last token remaining is the eapi . > > it doesn't clash with the existing system for 2 reasons, 1) the .eb > extension and 2) "eapi5" is not a valid version token That's logical, but as pointed out, the originally proposed delimiter was -, so dev-foo/foo-bar-2.3.4-eapi5.eb, which is a bit different. I've wondered about other delimiters, too. : seems obvious, but also rather likely to screw stuff up. What about something like ^ : dev-foo/foo-bar-2.3.4^eapi5.eb ? Or + dev-foo/foo-bar-2.3.4+eapi5.eb ? But my real reason for this post, and mostly picking your post to reply to as it's a convenient demonstration of .eb... Someone raised the point about "eb" being taken as a swear word in Russian. That might not be enough to derail it as the only choice, just as .fuck if it was the only thing available shouldn't be derailed, but surely there's other possible choices that aren't so objectionable. I haven't seen these suggested yet: .ebld .ebd .bld .dliube (backward, like xvid/vidx) .dlbe .be (ok, that's a 2-letter national code, but is it a swear word anywhere? if not I'd say it's still better). We could even do an inside joke on eb/ebb and make it .flow ... or for that matter, .eflow or .ebflow =:^) Some of those might have their own negative connotations or indeed, simply look too ugly, but that's the reason I'm asking. -- 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
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, 13 Mar 2012 02:41:13 -0400 "Walter Dnes" wrote: > On Mon, Mar 12, 2012 at 05:12:28PM +, Ciaran McCreesh wrote > > This whole thing is just an exercise in trying to find excuses not > > to use GLEP 55. > > A filename should not be (ab)used as a database. You mean we shouldn't have name, version and format in there? Because those are there already. All GLEP 55 does is make the format part more specific. > 1) Let's talk generic. Right now, we're talking about EAPI. In > future, what other (meta)data and characteristics will we need to > know? What else will be tacked onto the filename? EAPI, and any > other critical (meta)data should be declared early on in the ebuild. > That's what the ebuild is for. EAPI is special. You need to know EAPI to be able to get the rest of the metadata. > 2) Any potential ebuild processor that's incapable of looking for > regex "^EAPI=" in a textfile, amd parsing the numbers that follow, > has no business being used to process ebuilds. That doesn't get you the EAPI. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Stabilization requests from users
On 3/12/12 7:58 PM, Marco Paolone wrote: > scarabeus recently posted on his blog [1] about submission of stabilization > requests from users. Since using bugzilla could be a mess of duplicated > entries, I was thinking about a "Stabilization Party" once a month for > example, > in order to have a coherent list of stabilizations, and users working togheter > with you developers. How does it sound? Don't worry about perfection (at least for now). Just start filing stabilization requests, and _if_ it results in a mess of duplicates (I don't think so) we can think about better process. By the way, commenting on existing stable requests (success reports are also valuable) is another great way to contribute. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format
On Mon, 2012-03-12 at 08:49 +, Robin H. Johnson wrote: > On Mon, Mar 12, 2012 at 08:52:20PM +1300, Kent Fredric wrote: > > On 11 March 2012 22:09, Brian Dolbec wrote: > > > > > > eg: > > > > > > Channel #gentoo-guis on the freenode network > > > or > > > #gentoo-guis on the freenode IRC network, > > > irc://irc.gentoo.org/gentoo-guis > > > > > > > Though a freeform text field is probably better for humans, I'd > > suggest having more explicit data available as an option, ie: > > > > Channel > > #gentoo-guis on the freenode network > +1 on this. > ... and just when I was beginning to think no one actually cared :) ... The proper form of an irc url is in my example "irc://irc.gentoo.org/gentoo-guis" and I took it from gentoo's irc channel page at http://www.gentoo.org/main/en/irc.xml . That would mean limiting a single field to just valid url's just like the field. irc://irc.gentoo.org/gentoo-guis The other thing I find with your example is that layman no longer uses that old style of xml. It still supports it, if you have that format for some overlay definitions. But does not fit the current repositories.xml format. Personally I would find it quite simple to use a reg expression to extract a valid irc url from a mixture of written text and url. #gentoo-guis on the freenode IRC network, irc://irc.gentoo.org/gentoo-guis So far there is not a gui for working with layman, so is all command line, including the output of layman -i some-overlay. Don't get me wrong, I have nothing aginst a layman gui. I actually ended up taking over layman's development because of it's lack of a good api for other apps to use. Namely porthole. Plus I fully intend to create a standalone gui for layman. Would it be better that I create 2 irc sub data types then? #gentoo-guis on the freenode IRC network irc://irc.gentoo.org/gentoo-guis So far it seems many/most systems do not come setup to recognize and take proper action for irc:// mime types like they do for http:// -- Brian Dolbec signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote > Perhaps a suggestion for the news item. I'd recommend that anybody > who needs an initramfs to mount /usr get that working BEFORE they > upgrade udev. This situation is a heck of a lot easier to figure out > if the system still can be booted when the initramfs doesn't work. Question... does it have to be an initramfs, or can the vast majority of simple cases be handled by a simple initscript in /bin or /sbin that mounts /usr, and does whatever else is required, before handing off control to /sbin/init. I've migrated to mdev, so I won't be seeing this problem, but a simple solution that works for 95% of users might be the way to go. For the more complex situations, an initramfs will be necessary. -- Walter Dnes
Re: [gentoo-dev] RFD : .ebuild is only bash
> On Tue, 13 Mar 2012, Brian Harring wrote:
> Perfectly valid, if stupid, bash:
> EAPI=3
> EAPI=4
> Which is the PM to choose? Because if your answer is "the first",
> then you need to keep in mind that any following code (including
> eclasses that test eapi) will be seeing the second during sourcing.
> Nice little gotcha, that one.
> I'm aware people have suggested "make EAPI readonly" to try and deal
> w/ this; that however means it'll break any PM that uses eval for
> loading the ebuild, and means that every ebuild sourcing for phase
> running will throw a complaint about EAPI being readonly.
For the moment, let's assume that we go that route and specify the
EAPI in a comment in the first line of the ebuild. The EAPI variable
can be made readonly if we do one of the following:
- One time change of the ebuild's extension, so old package managers
won't see the new ebuilds.
- Specify the EAPI in the header, plus an assignment that is only seen
by old package managers (that don't get the EAPI variable from the
ebuild's header). All of the following should work:
: ${EAPI=5}
: ${EAPI=unsupported}
[[ ${EAPI} ]] || EAPI=-1
Any value for the EAPI can be used, as long as it's unknown to old
package managers.
- A variant of the above, if an EAPI would add features that make
sourcing of the ebuild with old package managers impossible:
[[ ${EAPI} ]] || { EAPI=-1; return; }
Testing this with current Portage (2.1.10.49) and two test ebuilds,
app-misc/foo-1 is EAPI 4, app-misc/foo-2 contains the above line:
# emerge -p app-misc/foo
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] app-misc/foo-1
foo-2 is masked by its unknown EAPI. No further warnings for the
user.
If I try to force installation of foo-2, I get the following:
# emerge -p =app-misc/foo-2
These are the packages that would be merged, in order:
Calculating dependencies... done!
!!! All ebuilds that could satisfy "=app-misc/foo-2" have been masked.
!!! One of the following masked packages is required to complete your
!!! request:
- app-misc/foo-2::x-ulm (masked by: missing keyword, invalid: SLOT:
invalid value: '', SLOT: undefined)
The current version of portage supports EAPI '4'. You must upgrade to a
newer version of portage before EAPI masked packages can be installed.
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
One line of spurious warnings because of missing KEYWORDS and SLOT,
because the ebuild returns before these lines can be assigned.
Otherwise, a clear message that the user should upgrade Portage.
(Arguably, adding a line like [[ ${EAPI} ]] || { EAPI=-1; return; }
to ebuilds wouldn't look elegant. See the above as proof of concept
that a readonly EAPI variable is possible.)
> I don't hugely expect PMs to screw up the ordering of which to
> chose, although it exists; trying to ban secondary settings is also
> an approach... but all of it points to the fact it's a fricking hack
> and isn't really worth doing.
> If we're going to redo EAPI, redo it right. Don't half ass it- this
> time around we're not forced to make compromises.
> Viewing it that way, this grep hack shouldn't be on the table as a
> viable option.
Agreed, it's a hack if we try parsing the bash assignment statement.
I don't see it as a hack if we have a well defined syntax for the
ebuild's first line.
Ulrich
[gentoo-dev] Re: Usecase for slotted gnupg
Excerpts from Andreas Herz's message of 2012-03-12 23:33:40 +0100:
> > I use mcabber with gnupg2 and it has no problem with pinentry.
>
> May i ask how you configured mcabber?
> Do you use the curses pinentry?
Gtk usually, but curses works fine, too. I haven't configured anything
special in mcabber - just:
set pgp = 1
set pgp_private_key = "MY HASH"
I use 0.10.1.
> Thanks for the hint with keychain, i will try this and also the ttl
> stuff.
This is how I run keychain in my ~/.bashrc:
keys="id_dsa id_rsa ABCDEF12 CDF12345" # ssh and gpg priv keys
if [[ $- != *i* ]] ; then
eval `keychain --eval ${keys} --quiet --noask --quick`
# Shell is non-interactive. Be done now!
return
fi
eval `keychain --eval ${keys} --quiet`
[[ $(tty) == /dev/tty[0-9] ]] && reset
So when I log into interactive shell first time (or after timeout), I'm
asked for pass phrases to unlock keys, and on non-interactive shell only
special environment vars are set.
> I also got it done with masking gnupg2 but i will try your suggestions
> so thanks so far. I just hope it will work with mcabber and also mutt
> then :)
GnuPG2 should work everywhere today, and if it doesn't work for some
app, then bug should reported for this app. (Although some crypto herd
member could take a voice here or at least confirm, what I wrote.)
Cheers,
--
Amadeusz Żołnowski
signature.asc
Description: PGP signature
[gentoo-dev] Re: Usecase for slotted gnupg
Hm, I have just realised that we're not discussing it on ml, and unnecessarily I've CC'ed it to ml, sorry. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Tue, Mar 13, 2012 at 2:43 AM, Walter Dnes wrote: > On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote > >> Perhaps a suggestion for the news item. I'd recommend that anybody >> who needs an initramfs to mount /usr get that working BEFORE they >> upgrade udev. This situation is a heck of a lot easier to figure out >> if the system still can be booted when the initramfs doesn't work. > > Question... does it have to be an initramfs, or can the vast majority > of simple cases be handled by a simple initscript in /bin or /sbin that > mounts /usr, and does whatever else is required, before handing off > control to /sbin/init. > > I've migrated to mdev, so I won't be seeing this problem, but a simple > solution that works for 95% of users might be the way to go. For the > more complex situations, an initramfs will be necessary. The devs are already discussing moving /bin/* to /usr/bin/* (if I understood correctly), so this will not last. And besides, genkernel and dracut are automatized; they *are* the simple (and proper, IMHO) solution. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On Mon, 12 Mar 2012 21:22:26 -0400 Joshua Kinard wrote: > On a somewhat sarcastic note, why don't we just deprecate /usr and > move everything back to /? Isn't that, largely, what is being > accomplished here? Solaris at least keeps some kernel stuff in / off > of /stand (I believe). Linux, after this /usr thing is fully > complete, about the only thing left in / that is of any value will > be /etc. Kernels were moved into /boot ages ago. A bit like stali? http://sta.li/ Or is that still too complicated? :) jer
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Tue, Mar 13, 2012 at 04:43:06AM -0400, Walter Dnes wrote: > Question... does it have to be an initramfs, or can the vast majority > of simple cases be handled by a simple initscript in /bin or /sbin that > mounts /usr, and does whatever else is required, before handing off > control to /sbin/init. Elsewhere on this list, you will find a script that does roughly what you propose, written by WilliamH and myself. We're not going to support it. There are too many corner cases that are hard to recover from with the script - and MUCH easier with the 'debug' argument to a genkernel initramfs. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format
On Tue, 13 Mar 2012 01:33:28 -0700 Brian Dolbec wrote: > The proper form of an irc url is in my example > "irc://irc.gentoo.org/gentoo-guis" and I took it from gentoo's irc > channel page at http://www.gentoo.org/main/en/irc.xml . Exactly. Most web browsers would know what to do with that, too. > That would mean limiting a single field to just valid > url's just like the field. > > irc://irc.gentoo.org/gentoo-guis Why not go with a slight variant of the venerable format? Your support channel is here Either that or use two tags, and nested in an tag? jer
Re: [gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format
On Tue, Mar 13, 2012 at 01:33:28AM -0700, Brian Dolbec wrote: > ... and just when I was beginning to think no one actually cared :) ... I specifically wanted to avoid any special regex to pull data out of the XML. Merging fields is acceptable, splitting them based on regex isn't. > The proper form of an irc url is in my example > "irc://irc.gentoo.org/gentoo-guis" and I took it from gentoo's irc > channel page at http://www.gentoo.org/main/en/irc.xml . The '#' is debated in the URL scheme specs. The last RFC draft I saw for it was: http://tools.ietf.org/html/draft-butcher-irc-url-04 Earlier drafts did explicitly call for dropping the '#', but that lead to trouble distinguishing between a user with the same name as a channel. > That would mean limiting a single field to just valid url's > just like the field. We can allow 0 or more irc fields in the DTD... > Personally I would find it quite simple to use a reg expression to > extract a valid irc url from a mixture of written text and url. > #gentoo-guis on the freenode IRC network, > irc://irc.gentoo.org/gentoo-guis Don't use a regex on XML. Actually connect it properly. > Would it be better that I create 2 irc sub data types then? > > > #gentoo-guis on the freenode IRC network > irc://irc.gentoo.org/gentoo-guis > No, that's really bloated. > So far it seems many/most systems do not come setup to recognize and > take proper action for irc:// mime types like they do for http:// It's not a mime type. It's URL scheme. Docbook/GuideXML style: Option 1a) Option 1b) For GUI issues in Gentoo HTML style: Option 2a) Option 2b) For GUI issues in Gentoo -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, Mar 13, 2012 at 2:29 AM, Richard Yao wrote: > To make XML a viable substitute for bash, you will need to implement a > turing complete language in XML, which should probably preclude its use > in ebuilds. You would likely have better luck with a functional > programming language, although you are more than welcome to demonstrate > otherwise. Well, a trivial solution to that is to embed bash code (or some other language) into the content of the xml file. As I and others posted earlier the advantage is that it makes all the key/value stuff easier to manage than doing it in bash, but it makes editing the scripting content harder and requires pre-processing before being fed into an interpreter. If you look at metadata.xml you could argue that we're already using xml-based ebuilds to an extent, but we split the metadata across two different files in different formats and call them different things. In any case, my point in bringing up xml was that the whole point of GLEP 55 was to future-proof the interpretation of ebuild files, and xml is just one example of what the future could conceivably look like. Rich
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 13 March 2012 01:22, Joshua Kinard wrote: > We should be working to getting rid of /usr and bring it all back into /, > then create temporary /usr symlinks to point programs in the right > direction. After all, /usr was originally for user data, not system data, > until someone cooked up /home (I don't know the full exact history here, so > feel free to correct me). > I believe that the Art of Unix Programming* says that /usr was the result of the original UNIX 4MB hard disk becoming full, and that they chose /usr to mount a second one. Every definition since then has been an attempt to justify preserving the split. * On reflection, I may have read this elsewhere.
[gentoo-dev] Re: Stabilization requests from users
On mar, 13 2012 08:46:06, "Paweł Hajdan, Jr." wrote: > On 3/12/12 7:58 PM, Marco Paolone wrote: >> scarabeus recently posted on his blog [1] about submission of stabilization >> requests from users. Since using bugzilla could be a mess of duplicated >> entries, I was thinking about a "Stabilization Party" once a month for >> example, >> in order to have a coherent list of stabilizations, and users working >> togheter >> with you developers. How does it sound? > > Don't worry about perfection (at least for now). > > Just start filing stabilization requests, and _if_ it results in a mess > of duplicates (I don't think so) we can think about better process. > > By the way, commenting on existing stable requests (success reports are > also valuable) is another great way to contribute. So, let's see how thing goes, eventually we can even talk again about it, if there will be problems. Thanks! -- Linux Registered User #401479 GPG: 0x897AF14E
Re: [gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?
On Mon, Mar 12, 2012 at 08:20:08PM +, Robin H. Johnson wrote: > On Mon, Mar 12, 2012 at 10:07:48PM +0200, Samuli Suominen wrote: > > ssmtp has been quiet project for quite a while, where as msmtp is > > maintained one. > > > > sure, ssmtp might be just mature, but msmtp is equally small and has > > more features. > > > > any thoughts? > +1 to getting rid of ssmtp. But I'm not sure that msmtp is the best > replacement. > > One of the greatest things that bugs me about ssmtp is that if the > mailserver is not available, it hangs for a while, and then it loses the > email. > > Where I need a simple mail relay, I've gone with nullmailer instead, > because it supports the features, and it explicitly has a lightweight > daemon mode that queues mail to send. At isolated places where i don't integrate my host into an existing mail setup, i use esmtp because it allows me to do local delivery of system mails (cron or similar jobs) by using a very simple setup: ~ $ cat /etc/esmtprc mda="/usr/bin/procmail -d %T" That's about the only config i need for this. Ok, it's not perfect because it requires procmail (no setup task required though) and cannot write the files directly. I think as an initial setup, something that just does local delivery for system mails out of the box is better than something that doesn't work unless you start configuring smart relay hosts etc. You can still do this if you integrate yourself into an existing mail setup. Christian
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/03/12 11:14 PM, Joshua Kinard wrote: > On 03/12/2012 22:33, Ian Stakenvicius wrote: > >> >> On 2012-03-12, at 9:22 PM, Joshua Kinard >> wrote: >> >>> >>> And yes, I've already tested out udev-181 on a VM with a >>> separate /usr. With devtmpfs, the system fully boots just >>> fine, no initramfs needed. Guess what the only piece of >>> software to mess up is? Udev. I largely think it's a timing >>> issue in OpenRC, however, because /usr DOES get mounted fairly >>> quickly, but not before udevd starts. But udevd does restart >>> itself and everything looks to work fine. If you aren't >>> watching the terminal, you wouldn't even notice the failures. >>> >> >> >> THANK YOU for testing this -- I could not forsee a reason, back >> when this process started, as to why openrc couldn't mount /usr >> before udev started. since devtmpfs should provide the source >> devnode anyways. It's good to have a (near) proof of that. >> >> Ian > > Yeah, I think it's an easy fix either in openrc or in an initscript > somewhere. I changed nothing except my kernel (was missing > devtmpfs -- it's not under Filesystems!), uninstalled > module-init-tools, and installed kmod + udev-181. Then rolled back > the snapshot once I had the results. Ah, right; kmod.. Tthere's pressure for that one to move to /usr too, isn't there mgorny? ok, nvm. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk9fTXIACgkQAJxUfCtlWe3RQQD8DIr8mZ773vIqhIxf5ERYWo8E ZkfDgAUlUDF7hcDiuUIA/1amWFFZcVu36V6vikq4HGF0we43YYMVLW6b96SblGzN =dKid -END PGP SIGNATURE-
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On 12.3.2012 1.15, William Hubbs wrote: >> >> How do you plan to handle notifying stable users if you go with > I was thinking of another news item once we are ready to go stable. > > What do you think? > > William > We could reuse the same news item if we now release it as >= and then release a new revision when it's ready for stable by changing the atom to <. This way stable users would not get the same item twice. Regards, Petteri
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard: [...] > After all, /usr was originally for user data, not system data, > until someone cooked up /home (I don't know the full exact history here, so > feel free to correct me). IIRC usr = unified system resources (not an abbrev. for "user") -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 12:03 AM, Brian Harring wrote: > On Tue, Mar 13, 2012 at 02:41:13AM -0400, Walter Dnes wrote: >> 2) Any potential ebuild processor that's incapable of looking for regex >> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no >> business being used to process ebuilds. > > Perfectly valid, if stupid, bash: > > EAPI=3 > EAPI=4 > > Which is the PM to choose? Because if your answer is "the first", > then you need to keep in mind that any following code (including > eclasses that test eapi) will be seeing the second during sourcing. > Nice little gotcha, that one. > > I'm aware people have suggested "make EAPI readonly" to try and deal > w/ this; that however means it'll break any PM that uses eval for > loading the ebuild, and means that every ebuild sourcing for phase > running will throw a complaint about EAPI being readonly. > > I don't hugely expect PMs to screw up the ordering of which to chose, > although it exists; trying to ban secondary settings is also an > approach... but all of it points to the fact it's a fricking hack and > isn't really worth doing. > > If we're going to redo EAPI, redo it right. Don't half ass it- this > time around we're not forced to make compromises. The "parse EAPI assignment" approach is more about fixing EAPI than redoing it. It's the least invasive approach, and it would work perfectly well in practice. Issues like the invalid double assignment that you mentioned, which are pretty unlikely anyway, are easily handled if package manager implements a feedback mechanism to assert that the parsed EAPI is identical to the value obtained from bash [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=402167#c18 -- Thanks, Zac
Re: [gentoo-dev] RFD : .ebuild is only bash
On 13.03.2012 07:22, Brian Harring wrote: > Still is god awfuly fugly though, and reliant on digits as the first > character to be readable. Consider exheres: > dev-foo/foo-bar-2.3.4.eapiexheres.eb Just for the record, your example is wrong. For exheres, it would be foo-bar-2.3.4.exheres-0 "0" being the version. Simple, elegant, works. Now please go on looking for a solution that takes (much) more effort and/or is more complicated as it suits my personal goals better if you choose something different, e. g. some kind of ebuild parsing. :-) Best regards, Wulf signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecate EAPI1?
On 03/11/2012 05:49 PM, Brian Harring wrote: > If people want to enforce the eapi1 is no longer used in the gentoo > repo, that's fine- we stick a list of acceptable EAPI's into > its layout.conf. That sounds pretty reasonable, although I think a deprecation warning would be more appropriate that an outright ban. A deprecation warning should be sufficient to send the intended message, without placing an unnecessary burden on people doing simple version bumps or adding ebuilds that are already well tested though they happen to use an older EAPI. -- Thanks, Zac
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, Mar 13, 2012 at 05:10:14PM +0100, Wulf C. Krueger wrote: > On 13.03.2012 07:22, Brian Harring wrote: > > Still is god awfuly fugly though, and reliant on digits as the first > > character to be readable. Consider exheres: > > dev-foo/foo-bar-2.3.4.eapiexheres.eb > > Just for the record, your example is wrong. For exheres, it would be > > foo-bar-2.3.4.exheres-0 > > "0" being the version. Simple, elegant, works. The example was right; you just didn't bother to read the thread. The proposal was to jam EAPI into the version namespace, rather than extension. Meaning they're proposing that foo-bar example be foo-bar-2.3.4.eapiexheres-0.ebuild As I said in the email you didn't bother to actually read, such a proposal is fairly whacked and takes away the actual benefits of G55; aka, do G55 before doing that attrocity. I'll skip replying to the rest of the snark in the email; I will however point out that toolish behaviour like above doesn't do G55 any favors in trying to reverse 5 years of people saying "I don't like the aesthetics". That said, feel free to keep screaming into the wind about it. ~harring
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, Mar 12, 2012 at 07:50:36PM +0100, Ulrich Mueller wrote: > > On Mon, 12 Mar 2012, Ciaran McCreesh wrote: > > GLEP 55 is simple, it solves all the problems we have (including the > > version issue, which everyone is conveniently ignoring), it doesn't > > require us to guess what's going to happen next and it can be > > implemented immediately. That's a rather big deal. > > The "header comment" solution solves all these issues too, without > embedding unrelated information in the filename [1]. It can be > implemented immediately, too. > > The argument that was always used against such solutions was that > it would "hurt performance". However, when the council asked for > benchmarks that would prove that point, nobody could provide them. Just a note... it's effectively background noise if implemented even halfway sanely, and that's clocking it from w/in pkgcore; for portage, it will be purely in the noise. That's not to say it's *efficient*- it's just not a real world performance concern. ~brian
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 13 March 2012 14:41, Marc Schiffbauer wrote: > Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard: > [...] >> After all, /usr was originally for user data, not system data, >> until someone cooked up /home (I don't know the full exact history here, so >> feel free to correct me). > > IIRC usr = unified system resources (not an abbrev. for "user") > > -Marc > -- > 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 Again, backwards justification for a directory name that was already in place.
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On 03/13/2012 01:11, Luca Barbato wrote: > > Our current init system doesn't have any problem with /usr being mounted > later, but udev might have issues. > > Same could be said about bluez and dbus. bluez and dbus aren't system-critical services, however. udev kinda is, along with key filesystem tools. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/13/2012 07:54, James Broadhead wrote: > On 13 March 2012 01:22, Joshua Kinard wrote: >> We should be working to getting rid of /usr and bring it all back into /, >> then create temporary /usr symlinks to point programs in the right >> direction. After all, /usr was originally for user data, not system data, >> until someone cooked up /home (I don't know the full exact history here, so >> feel free to correct me). >> > > I believe that the Art of Unix Programming* says that /usr was the > result of the original UNIX 4MB hard disk becoming full, and that they > chose /usr to mount a second one. Every definition since then has been > an attempt to justify preserving the split. Sounds like how a lot of UNIXy things came into being. This is why I think /usr should be merged back into /, not the other way around. Although, both approaches essentially achieve the same effect in the end, once you move /etc and a few other bits, then point the kernel at "/usr". -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/13/2012 01:17, Luca Barbato wrote: > > So you need need a smaller udev that is completely self contained and make > sure anything needed for the key rules works. I wonder if the pci-ids cannot > stay somewhere in /etc or /lib > > lu I think gregkh is already on record as saying that the pci-ids file is going to go into /usr and stay there. The errors I got weren't from that, though, it was the init scripts trying to find udevadm, and then not finding libkmod, which was likely installed into /usr/lib64. I guess I don't run a "standard" Linux system anymore. I build a fairly monolithic kernel that contains device drivers for all the hardware in the machine needed to get it up and running, while miscellaneous modules (like CIFS or the Happy MEal quad ethernet card) are modulues. My MIPS systems all run pure monolithic, completely lacking module support entirely. The trend now seems to be to modularize everything these days, even stuff like the core disk drivers, then build those core modules into an initramfs that the kernel cherrypicks from at boot. That's the perception, anyways, and one which I don't really get. Correct me if I'm wrong... -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, Mar 13, 2012 at 07:30:22AM +, Ciaran McCreesh wrote > EAPI is special. You need to know EAPI to be able to get the rest of > the metadata. > > > 2) Any potential ebuild processor that's incapable of looking for > > regex "^EAPI=" in a textfile, amd parsing the numbers that follow, > > has no business being used to process ebuilds. > > That doesn't get you the EAPI. On Tue, Mar 13, 2012 at 12:03:34AM -0700, Brian Harring wrote > Perfectly valid, if stupid, bash: > > EAPI=3 > EAPI=4 > > Which is the PM to choose? Because if your answer is "the first", > then you need to keep in mind that any following code (including > eclasses that test eapi) will be seeing the second during sourcing. > Nice little gotcha, that one. > > I'm aware people have suggested "make EAPI readonly" to try and deal > w/ this; that however means it'll break any PM that uses eval for > loading the ebuild, and means that every ebuild sourcing for phase > running will throw a complaint about EAPI being readonly. > > I don't hugely expect PMs to screw up the ordering of which to chose, > although it exists; trying to ban secondary settings is also an > approach... but all of it points to the fact it's a fricking hack and > isn't really worth doing. I'm answering Ciaran's and Brian's posts together, because the answer is the same for both... namely, we need a 2-pass processor, regardless of whether it's bash/perl/python/whatever. Pass 1 checks for syntax errors and retrieves "special" variables, answering Ciaran's concern. Today, it's EAPI. In future, there may be others. Pass 2 does the build, assuming no errors detected in pass 1. Under the heading of "syntax errors", I would include multiple EAPI declarations. My response to Brian is that portage should not try to outguess or fix or override an obviously broken ebuild. It should return an error message (in this case "Multiple EAPI declarations not allowed") and then halt. It is the ebuild-writer's job to come up with a syntactically correct ebuild. -- Walter Dnes
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On 03/13/2012 05:14, Canek Peláez Valdés wrote: > > And besides, genkernel and dracut are automatized; they *are* the > simple (and proper, IMHO) solution. My contention is that I shouldn't need an initramfs loaded into my kernel to get my system into a minimally-usable state. I've been running separate /usr setups for 10+ years, and only now, such a setup breaks, hence my beef with Fedora's assertion that such a setup is wrong. And I'm not even doing anything fancy! No encryption, no lvm/evms, no software RAID (on x86/x64 -- MIPS systems run mdadm), plain ext3/ext4 filesystems. I *shouldn't* need to start including an initramfs in my kernel to work around this. make menuconfig, make [, make modules[_install]], then update the bootloader, is how I've done kernels for the longest time. This new approach makes the above command sequence invalid if under a separate /usr. From a technical perspective, my argument is a moot point and is easily remedied. But I'm making it from a more philosophical standpoint because what once was a working setup, however uncommon, is not any more, and that to me is broken. I've essentially lost some amount of "freedom" in my choice of running a Linux box. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Tue, 2012-03-13 at 20:29 -0400, Joshua Kinard wrote: > On 03/13/2012 05:14, Canek Peláez Valdés wrote: > > > > > And besides, genkernel and dracut are automatized; they *are* the > > simple (and proper, IMHO) solution. > > > My contention is that I shouldn't need an initramfs loaded into my kernel to > get my system into a minimally-usable state. I've been running separate > /usr setups for 10+ years, and only now, such a setup breaks, hence my beef > with Fedora's assertion that such a setup is wrong. You simply misunderstood their point -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 08:29 PM, Walter Dnes wrote: I'm answering Ciaran's and Brian's posts together, because the answer is the same for both... namely, we need a 2-pass processor, regardless of whether it's bash/perl/python/whatever. Pass 1 checks for syntax errors and retrieves "special" variables, answering Ciaran's concern. Today, it's EAPI. In future, there may be others. Pass 2 does the build, assuming no errors detected in pass 1. Problem is, the only thing that can tell if there's a bash syntax error is bash itself.
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On Tue, Mar 13, 2012 at 8:20 PM, Joshua Kinard wrote: > The trend now seems to be to modularize everything these days, even stuff > like the core disk drivers, then build those core modules into an initramfs > that the kernel cherrypicks from at boot. That's the perception, anyways, > and one which I don't really get. Well, on most distros the kernel is just another package that is the same on every box. If you want one kernel for every PC, then it needs to support every piece of hardware in existence. So, either it is highly modular, or it is going to suck up a ton of RAM. The solution is a one-size-fits-all kernel, combined with a one-size-fits-all initramfs. For Gentoo where people build their own kernels, it doesn't make as much sense. Rich
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Wed, Mar 14, 2012 at 02:29, Joshua Kinard wrote: > make menuconfig, make [, make modules[_install]], then > update the bootloader, is how I've done kernels for the longest time. This > new approach makes the above command sequence invalid if under a separate > /usr. If your /usr doesn't require kernel modules (e.g., same harddisk and filesystem as /), you can create an initramfs consisting of Busybox and 2-line /init (mount /usr and switch_root), and forget about it after adjusting bootloader configuration. I guess that OpenRC could even opportunistically try to "fstabinfo --mount /usr 2>/dev/null" in init.sh to support such usecases. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Tue, Mar 13, 2012 at 08:29:31PM -0400, Joshua Kinard wrote: > make menuconfig, make [, make modules[_install]], then > update the bootloader, is how I've done kernels for the longest time. This > new approach makes the above command sequence invalid if under a separate > /usr. And why does the requirement to create an initramfs ONCE and include in your bootloader change that? The minimal genkernel example I provided explicitly excludes all modules from the initramfs, so that you almost never have to update it (just for new features/bugfixes really). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, Mar 13, 2012 at 08:29:03PM -0400, Walter Dnes wrote: > On Tue, Mar 13, 2012 at 07:30:22AM +, Ciaran McCreesh wrote > > > EAPI is special. You need to know EAPI to be able to get the rest of > > the metadata. > > > > > 2) Any potential ebuild processor that's incapable of looking for > > > regex "^EAPI=" in a textfile, amd parsing the numbers that follow, > > > has no business being used to process ebuilds. > > > > That doesn't get you the EAPI. > > On Tue, Mar 13, 2012 at 12:03:34AM -0700, Brian Harring wrote > > > Perfectly valid, if stupid, bash: > > > > EAPI=3 > > EAPI=4 > > > > Which is the PM to choose? Because if your answer is "the first", > > then you need to keep in mind that any following code (including > > eclasses that test eapi) will be seeing the second during sourcing. > > Nice little gotcha, that one. > > > > I'm aware people have suggested "make EAPI readonly" to try and deal > > w/ this; that however means it'll break any PM that uses eval for > > loading the ebuild, and means that every ebuild sourcing for phase > > running will throw a complaint about EAPI being readonly. > > > > I don't hugely expect PMs to screw up the ordering of which to chose, > > although it exists; trying to ban secondary settings is also an > > approach... but all of it points to the fact it's a fricking hack and > > isn't really worth doing. > > I'm answering Ciaran's and Brian's posts together, because the answer > is the same for both... namely, we need a 2-pass processor, regardless > of whether it's bash/perl/python/whatever. Pass 1 checks for syntax > errors and retrieves "special" variables, answering Ciaran's concern. > Today, it's EAPI. In future, there may be others. Pass 2 does the > build, assuming no errors detected in pass 1. With respect, this statement carries no actual weight nor usefulness. PMs, by nature of dep resolution/building, already have that effective seperation. The point of this whole discussion is how to get metadata out of the ebuild w/out excessive burdens on future formats. This pass1/pass2 doesn't address that at all, nor actually relevant to the discussion at hand. Not trying to be a complete dick here, but you completely missed the points being discussed including actually responding to ciaran's point. I suggest you grab the sources of whichever PM you use, and audit how it gets metadata- it would help for understanding and contributing to this discussion. At the very least it would be useful having another person besides the Ulm/3 PM authors who actually are familiar w/ how this actually works at the core. > Under the heading of "syntax errors", I would include multiple EAPI > declarations. My response to Brian is that portage should not try to > outguess or fix or override an obviously broken ebuild. It should > return an error message (in this case "Multiple EAPI declarations not > allowed") and then halt. It is the ebuild-writer's job to come up with > a syntactically correct ebuild. And it's the PMs responsibility to enforce the rules of the environment; there in is part of the problem- portage is generally pretty lax about any form of strictness there, and has historically been that way. Even if one couldn't just point at portage, there still would be the problem of 3 different managers all needing to enforce the same tricky environment restrictions. Leaving it such that the PM has to enforce things like "don't have multiple EAPI assignments" means by default, one of them isn't going to... leading to the ebuilds breaking... specifically the common case being the ebuild becoming acclimated to some quirk of portage. EAPI was started to try and address that sensitivity (including rolling out new features), and the literal history of EAPI has involved dealing w/ quirks of portages past behaviour- including pre EAPI0. Generally speaking, the less ways something can be screwed up means less ways something *will* be screwed up. My point was that this can be pretty easily screwed up, and isn't as simple to enforce as people seem to think- that's not counting just flat out issues w/ the actual usage of it. ~brian
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, Mar 12, 2012 at 09:05:26AM -0700, Zac Medico wrote: > On 03/12/2012 01:36 AM, Brian Harring wrote: > > On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote: > >> 1) User downloads an overlay that doesn't provide cache. We want the > >> package manager to give a pretty "EAPI unsupported" message, rather than > >> spit out some bash syntax errors. > > > > This criticsm pretty much applies *strictly to the existing > > implementation*. It's disenguous busting it in this fashion. > > > > EAPI as a function explicitly gives it an out before hitting any of > > that, eliminating your entire critique. Same goes for parsing it out > > of the ebuild, or renaming the extension. > > You're assuming that the ebuild calls your eapi() function before it > uses any syntax that's unsupported by the user's installed version of bash. A bit, although that's a pretty valid assumption frankly. For current bash syntax, the only thing they could do that would cause issues is bash regex's for example- which if they have regex's prior to the eapi invocation, they're doing something stupid anyways. Regardless, detecting and suppressing isn't too hard- start sourcing w/ `set -e`, disabling that once `eapi` has been invoked for example. Pretty sure people will scream "that's horrible", but it's surprisingly effective. > > 1) PM still doesn't support that EAPI, looks at the cache/ebuild: > > checksums are the same, thus the stored EAPI is trustable, leading to > > the PM knowing it still can't process that ebuild and masking it > > appropriately. > > You're assuming that cache is provided by the repo, Sigh. I'm making no such assumptions, nor would I; it's a stupid line of thought. All of this has to function in the absence of a cache, and that's a core usage scenario. > which is not > guaranteed, depending on the source. Even if the cache does exist, then > you're assuming it's in a format that the package manager can reliably > parse the EAPI from, even though that EAPI may not be supported. That > may or may not reliable assumption, and having a pre-defined protocol to > directly obtain the EAPI without using the cache is much more reliable. This is a nonstatement. To deal w/ the cache (validate it) you have to be able to reliably pull EAPI out of the ebuild. That's what this whole fucking discussion is about; really not sure why you're trying to argue this point against eapi as a function. As I already laid out, it can deal w/it, same as the rest. Importantly, the approach can also work across the transition period preventing current-day PMs (using current EAPI mechanisms) from breaking when used against later EAPIs that were released via `eapi as a function`. > > What I'd like to see, is accuracy in this discussion. Skip the > > handwavey "complexity! complexity! complexity!" crap, same for > > selective robustness definitions. Past attempts at this discussion > > mostly failed due to people pulling crap like this and frankly it just > > pisses people off. > > It's just a symptom of people not abiding by the KISS principle. When > you start talking about an approach such as the "eapi() function" > approach which introduces lots of unnecessary complexity, it naturally > makes the whole discussion more complex and hand-wavey. With respect; you're proposing we go gum up version parsing via shoving EAPI directly into it. Literally, make what is already a complex mess, worse. Apply some KISS to your proposal please. ;) Just hammering the point home; compatibility *is* complex. Claiming otherwise is naive. Case in point: your proposal breaks the shit out of any current-day package manager that saw such a filename. I really have a hard time reading your posts when basic issues like that aren't paid attention to, but you've no problems claiming complexity/brokenness in other proposals. As I said, I'd like to see some accuracy; not hand wavy buzzwords. I'd much more like to see prototypes of peoples proposals in addition since at least that way they would flush out the breakages in their proposals (potentially dropping it in the process since some of these are pretty half baked). ~brian
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 06:42 PM, Brian Harring wrote: > Leaving it such that the PM has to enforce things like "don't have > multiple EAPI assignments" means by default, one of them isn't going > to... leading to the ebuilds breaking... specifically the common case > being the ebuild becoming acclimated to some quirk of portage. My intention is for PMS to specify the search algorithm that's used to probe the EAPI, and also for it to specify that package managers must treat an ebuild as invalid if the probed EAPI is not identical to the one that's obtained from bash. If all package managers adhere strictly to these two requirements, then we won't have any incompatibilities between package managers here. -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/13/2012 07:01 PM, Brian Harring wrote: > With respect; you're proposing we go gum up version parsing via > shoving EAPI directly into it. Literally, make what is already a > complex mess, worse. Apply some KISS to your proposal please. ;) > > Just hammering the point home; compatibility *is* complex. Claiming > otherwise is naive. Case in point: your proposal breaks the shit out > of any current-day package manager that saw such a filename. I'm not really interested in GLEP 55 or variants of it. I was just saying that if we do go with a GLEP 55 variant, then I'd prefer one that's similar to the "EAPI in the filename with one-time extension change" option [1]. There are plenty of ways to do that without making it difficult to separate the EAPI from the version part. [1] http://www.gentoo.org/proj/en/glep/glep-0055.html#eapi-in-the-filename-with-one-time-extension-change -- Thanks, Zac
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 10:05 PM, Zac Medico wrote: On 03/13/2012 06:42 PM, Brian Harring wrote: Leaving it such that the PM has to enforce things like "don't have multiple EAPI assignments" means by default, one of them isn't going to... leading to the ebuilds breaking... specifically the common case being the ebuild becoming acclimated to some quirk of portage. My intention is for PMS to specify the search algorithm that's used to probe the EAPI, and also for it to specify that package managers must treat an ebuild as invalid if the probed EAPI is not identical to the one that's obtained from bash. If all package managers adhere strictly to these two requirements, then we won't have any incompatibilities between package managers here. Someone should really throw up a table on wiki.g.o with a comparison of the proposed methods. IIRC, the pros/cons of this in contrast to GLEP 55 are something like, Pro: * We don't need to change the filename, and "ebuild" is nice * GLEP 55 pissed people off, and was already rejected * Some people think the EAPI rightfully belongs in the ebuild Cons: * New features can't be implemented immediately because PMs have to catch up first. * Slight performance hit * Old package managers on out-of-date systems will barf on it * It involves using a magic identifier, e.g. a comment. Magic is bad, and the fact that messing with a comment can break your PM is counter-intuitive. * Some people think the EAPI rightfully belongs in the filename and the last one is worth the most points to everyone anyway.
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 07:23 PM, Michael Orlitzky wrote: > Someone should really throw up a table on wiki.g.o with a comparison of > the proposed methods. We've got one already: http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms -- Thanks, Zac
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 10:36 PM, Zac Medico wrote: On 03/13/2012 07:23 PM, Michael Orlitzky wrote: Someone should really throw up a table on wiki.g.o with a comparison of the proposed methods. We've got one already: http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms *facepalm*
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, Mar 13, 2012 at 07:05:57PM -0700, Zac Medico wrote: > On 03/13/2012 06:42 PM, Brian Harring wrote: > > Leaving it such that the PM has to enforce things like "don't have > > multiple EAPI assignments" means by default, one of them isn't going > > to... leading to the ebuilds breaking... specifically the common case > > being the ebuild becoming acclimated to some quirk of portage. > > My intention is for PMS to specify the search algorithm that's used to > probe the EAPI, and also for it to specify that package managers must > treat an ebuild as invalid if the probed EAPI is not identical to the > one that's obtained from bash. *Now* is when you should be applying your KISS wikipedia links (moreso, the principle applied to your proposal). What you're talking about is requiring PMs to monitor what occured and bail- rather than precluding it from even occuring. I repeat; try to spot the situation and make things blow up, rather than disallowing it from occuring in the first place. It's really that simple; this is why the "grep the assignment" out of the source is at its core, a well intentioned but fundamentally bad idea. It's glue on a bad situation rather than just removing the bad situation. > If all package managers adhere strictly > to these two requirements, then we won't have any incompatibilities > between package managers here. You're missing a lot of the point here; defining some search algo is basically screwed at its core due to the flexibility of bash. Simple example: if [ "$PV" -eq ]; then EAPI=3 else EAPI=2 fi The flexibility of bash means that your attempt to enforce simplistic rules like "it must be greppable" are at loggerheads; if the rules were "last is the one thats used", then I just invert the if check. Yep, the above is stupid code. Frankly, the sort of stupid code I'd expect out of a newbie ebuild dev. The EAPI bit there is synthetic, but that sort of construct (putting everything into a single file, then using symlinks to expose differing versions) is out in the wild and used. The fact that potential exists is a flat out sign the approach is broken. Worse, it's a way to trip up people- specifically new devs who don't know fun rules like "the PM has this lovely search algo for getting EAPI that you must abide by". ~brian
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/2012 07:38 PM, Brian Harring wrote: > On Tue, Mar 13, 2012 at 07:05:57PM -0700, Zac Medico wrote: >> If all package managers adhere strictly >> to these two requirements, then we won't have any incompatibilities >> between package managers here. > > You're missing a lot of the point here; defining some search algo is > basically screwed at its core due to the flexibility of bash. Simple > example: > > if [ "$PV" -eq ]; then > EAPI=3 > else > EAPI=2 > fi > > The flexibility of bash means that your attempt to enforce simplistic > rules like "it must be greppable" are at loggerheads; if the rules > were "last is the one thats used", then I just invert the if check. > > Yep, the above is stupid code. Frankly, the sort of stupid code > I'd expect out of a newbie ebuild dev. The EAPI bit there is > synthetic, but that sort of construct (putting everything into a > single file, then using symlinks to expose differing versions) is out > in the wild and used. > > The fact that potential exists is a flat out sign the approach is > broken. Worse, it's a way to trip up people- specifically new devs > who don't know fun rules like "the PM has this lovely search algo for > getting EAPI that you must abide by". It won't be a problem because the package manager can reject the ebuild as soon as the dev tries to execute it the first time, and it will refer the dev to the section of PMS that specifies the search algorithm. As for ebuilds in the wild that already do stuff like that, it's not a problem if we only require the search algorithm to work starting with EAPI 5. -- Thanks, Zac
