Re: [gentoo-dev] [discussion] GitHub eclass
On Fri, Feb 22, 2013 at 9:00 AM, Michał Górny wrote: > > You can also use git-2 eclass-specific variables to switch the repo. > The only difference is that you need to specify the full repo URI > rather than just the author. The full repo URI is actually copy-pastable from github, while breaking everything up requires a few steps to configure it all. I could see some value in being able to switch forks, but that seems like a bit of a niche. If you REALLY want to follow another fork you're better off creating a new ebuild rather than just overriding the environment variable. You can also override the repo URI if it uses the git eclass and again that can be copy/pasted. As Diego/Ian pointed out, we can't really apply this well to anything but live ebuilds. Rich
Re: [gentoo-dev] [discussion] GitHub eclass
On Fri, 22 Feb 2013 10:53:46 +0400 "Vadim A. Misbakh-Soloviov" wrote: > We have, for example, lua-socket-, that uses: > GH_AUTHOR=diegonehab > GH_PROJECT=lua-socket > GH_BRANCH=unstable > > So, then I fork it and provide some features. And then I want to > reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do: > # GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket- > and it repulls sources from my fork, reemerge it and installs fine. You can also use git-2 eclass-specific variables to switch the repo. The only difference is that you need to specify the full repo URI rather than just the author. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [discussion] GitHub eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/02/13 04:51 AM, Kent Fredric wrote: > On 22 February 2013 20:43, Diego Elio Pettenò > wrote: >> On 22/02/2013 08:37, Kent Fredric wrote: >>> I'd make sure to add some sort of easy support to switch to >>> snapshotted tar.gz installs instead of live git checkouts, ie: >>> >>> GH_SNAPSHOT=deadbeef # use commit id 'deadbeef' by fetching a >>> tar.gz from github instead of a git clone >> >> This is not going to fly because a live git checkout does not >> need digests in the manifest, but a tar.gz snapshot does. > > Though surely you could have behaviour that differs based on the > right things being specified, so that turning on GH_SNAPSHOT= > becomes a helper that generates SRC_URI , which in turn makes it so > you can satisfy the manifest digest requirement. SRC_URI can't be dynamic though, due to metadata cacheing. If GH_SNAPSHOT was always set and its value never changed, it would not be a problem, but that would seem to contradict the point of this variable..? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEnd3gACgkQ2ugaI38ACPCSkQD/eAbmFydGNta2HbUc2YyQYg05 ISKyLksP5PZ4BGbr9fwA/jx6M9pFGbFH2HYkx++MTTKXiLTGs6v3wxT8NjeBK6hv =jUew -END PGP SIGNATURE-
Re: [gentoo-dev] [discussion] GitHub eclass
On 22 February 2013 20:43, Diego Elio Pettenò wrote: > On 22/02/2013 08:37, Kent Fredric wrote: >> I'd make sure to add some sort of easy support to switch to >> snapshotted tar.gz installs instead of live git checkouts, ie: >> >> GH_SNAPSHOT=deadbeef # use commit id 'deadbeef' by fetching a tar.gz >> from github instead of a git clone > > This is not going to fly because a live git checkout does not need > digests in the manifest, but a tar.gz snapshot does. Though surely you could have behaviour that differs based on the right things being specified, so that turning on GH_SNAPSHOT= becomes a helper that generates SRC_URI , which in turn makes it so you can satisfy the manifest digest requirement. -- Kent
Re: [gentoo-dev] [discussion] GitHub eclass
On 22/02/2013 08:37, Kent Fredric wrote: > I'd make sure to add some sort of easy support to switch to > snapshotted tar.gz installs instead of live git checkouts, ie: > > GH_SNAPSHOT=deadbeef # use commit id 'deadbeef' by fetching a tar.gz > from github instead of a git clone This is not going to fly because a live git checkout does not need digests in the manifest, but a tar.gz snapshot does. I'm not against having a common way to deal with github project as they are common, but just having a wrapper for a few variables is not worth it IMHO. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [discussion] GitHub eclass
On 22 February 2013 19:53, Vadim A. Misbakh-Soloviov wrote: > Hi there! > > Since we have tons of ebuild (including -) for software, that uses > GitHub for sourcecode hosting — I've got an idea to write something > like GitHub eclass, which will ease creating of such ebuilds (by > providing "sugar" functions) and, (main goal for me) by adding > possibility to switch between forks (by redefining variables on emerge > run). For example (theoretical usecase): > > We have, for example, lua-socket-, that uses: > GH_AUTHOR=diegonehab > GH_PROJECT=lua-socket > GH_BRANCH=unstable > > So, then I fork it and provide some features. And then I want to > reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do: > # GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket- > and it repulls sources from my fork, reemerge it and installs fine. I'd make sure to add some sort of easy support to switch to snapshotted tar.gz installs instead of live git checkouts, ie: GH_SNAPSHOT=deadbeef # use commit id 'deadbeef' by fetching a tar.gz from github instead of a git clone -- Kent
[gentoo-dev] [discussion] GitHub eclass
Hi there! Since we have tons of ebuild (including -) for software, that uses GitHub for sourcecode hosting — I've got an idea to write something like GitHub eclass, which will ease creating of such ebuilds (by providing "sugar" functions) and, (main goal for me) by adding possibility to switch between forks (by redefining variables on emerge run). For example (theoretical usecase): We have, for example, lua-socket-, that uses: GH_AUTHOR=diegonehab GH_PROJECT=lua-socket GH_BRANCH=unstable So, then I fork it and provide some features. And then I want to reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do: # GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket- and it repulls sources from my fork, reemerge it and installs fine. Any ideas/suggestions/objections/critic? Let's discuss! -- Best regards, mva signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Discussion
On Thursday 11 May 2006 14:19, Jan Kundrát wrote: > s/GLEP 42/boring -dev threads which are completely OT/ Ehi, I find this more interesting than what the original was going to be :P -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgplSYoZy2s3A.pgp Description: PGP signature
Re: [gentoo-dev] Discussion
Diego 'Flameeyes' Pettenò wrote: On Thursday 11 May 2006 14:01, Martin Ehmsen wrote: Syntax error! More than syntax is me who was sleeping. I just meant that it gave a syntax error (after applying your sed) Although I suppose this means we all agree ;) Definitely! Maybe we should propose a new GLEP which requires GLEPs to be fun? :) /Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
Diego 'Flameeyes' Pettenò wrote: > Although I suppose this means we all agree ;) s/GLEP 42/boring -dev threads which are completely OT/ :-P Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Discussion
On Thursday 11 May 2006 14:01, Martin Ehmsen wrote: > Syntax error! More than syntax is me who was sleeping. Although I suppose this means we all agree ;) -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpoO9vQHNk2s.pgp Description: PGP signature
Re: [gentoo-dev] Discussion
Diego 'Flameeyes' Pettenò wrote: On Thursday 11 May 2006 06:44, Mike Frysinger wrote: or because reading GLEP 42 is boooring s/42 /s/ Syntax error! s/ 42/s/ instead. /Ehmsen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
On Thursday 11 May 2006 12:45, Diego 'Flameeyes' Pettenò wrote: > On Thursday 11 May 2006 06:44, Mike Frysinger wrote: > > or because reading GLEP 42 is boooring > > s/42 /s/ s/is/are/ -- Roy Marples <[EMAIL PROTECTED]> Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
On Thursday 11 May 2006 06:44, Mike Frysinger wrote: > or because reading GLEP 42 is boooring s/42 /s/ -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpRyy2cd84qO.pgp Description: PGP signature
Re: [gentoo-dev] Discussion
On Wednesday 10 May 2006 13:26, Ciaran McCreesh wrote: > Because he wasn't paying attention? Or because he knew fine well and > just felt like taking a dig... or because reading GLEP 42 is boooring -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
On Wednesday 10 May 2006 01:26 pm, Ciaran McCreesh wrote: > On Wed, 10 May 2006 10:13:36 -0700 Donnie Berkholz > > <[EMAIL PROTECTED]> wrote: > | Ciaran McCreesh wrote: > | > On Wed, 10 May 2006 00:07:29 -0700 Donnie Berkholz > | > > | > <[EMAIL PROTECTED]> wrote: > | > | so discussion with at least the portage team would be merited. > | > > | > Already happened, in amongst all the other GLEP 42 stuff. > | > | Then I wonder why a member of the portage team was taken by surprise? > > Because he wasn't paying attention? Or because he knew fine well and > just felt like taking a dig... > It was discussed a while back yes, there was no firm "this is what will be done" and I don't have any issues with what was put into the tree. As I stated on IRC, I'd like a heads up if things there are going to change, as it affects more than just you ( or paludis ). All I request is an attempt to keep each other informed. I try to e-mail this list whenever stuff like that changes (I think I changed info_pkg's a while ago, for example) to let people know whats going on; I ask that you do the same. > -- > Ciaran McCreesh > Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
On Wed, 10 May 2006 10:13:36 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > On Wed, 10 May 2006 00:07:29 -0700 Donnie Berkholz | > <[EMAIL PROTECTED]> wrote: | > | so discussion with at least the portage team would be merited. | > | > Already happened, in amongst all the other GLEP 42 stuff. | | Then I wonder why a member of the portage team was taken by surprise? Because he wasn't paying attention? Or because he knew fine well and just felt like taking a dig... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
Ciaran McCreesh wrote: > On Wed, 10 May 2006 00:07:29 -0700 Donnie Berkholz > <[EMAIL PROTECTED]> wrote: > | so discussion with at least the portage team would be merited. > > Already happened, in amongst all the other GLEP 42 stuff. Then I wonder why a member of the portage team was taken by surprise? Thanks for the clarification, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Discussion
On Wed, 10 May 2006 00:07:29 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: | so discussion with at least the portage team would be merited. Already happened, in amongst all the other GLEP 42 stuff. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
Stephen Bennett wrote: > On Tue, 09 May 2006 18:27:45 -0700 > Donnie Berkholz <[EMAIL PROTECTED]> wrote: > >> Then again, I'm missing context because people have this weird thing >> about abstractly bringing up issues without discussing the actual >> problem. > > The context is that I added profiles/repo_name to the tree ~5 days ago, > in order to properly take advantage of functionality available in a > certain package available in the tree (sys-apps/paludis). It's 7 bytes > and doesn't adversely affect anything, so I didn't deem it particularly > worth making a fuss about. Stephen, thanks for this useful clarification. As far as I know, every file in profiles/ is used by Gentoo's package manager or QA tools. Changing that by adding a file used by something other than portage/repoman is a policy change. It also may turn out that portage itself could make use of a similar file to what you're adding for paludis, so discussion with at least the portage team would be merited. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Discussion
Roy Marples wrote: > On Wednesday 10 May 2006 01:17, Alec Warner wrote: >> Please don't commit files to profiles/ unless it has been discussed >> previously on this ML. I don't care if your file is insignificant or >> 'won't affect anything else' or that it's 'completely necessary'. Please >> discuss it first. > > Surely you don't include package.mask, use.local.dec in that list do you? There's a different between "commit files" and "commit to files" -- the first has an implied "new" =) Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Discussion
On Wednesday 10 May 2006 01:17, Alec Warner wrote: > Please don't commit files to profiles/ unless it has been discussed > previously on this ML. I don't care if your file is insignificant or > 'won't affect anything else' or that it's 'completely necessary'. Please > discuss it first. Surely you don't include package.mask, use.local.dec in that list do you? -- Roy Marples <[EMAIL PROTECTED]> Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
On Tue, 09 May 2006 18:27:45 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Then again, I'm missing context because people have this weird thing > about abstractly bringing up issues without discussing the actual > problem. The context is that I added profiles/repo_name to the tree ~5 days ago, in order to properly take advantage of functionality available in a certain package available in the tree (sys-apps/paludis). It's 7 bytes and doesn't adversely affect anything, so I didn't deem it particularly worth making a fuss about. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion
Alec Warner wrote: > Please don't commit files to profiles/ unless it has been discussed > previously > on this ML. I don't care if your file is insignificant or 'won't affect > anything else' or that it's 'completely necessary'. Please discuss it first. > > You don't have to ask for a vote on it, or make everyone agree with you. You > don't even need to wait three weeks to make sure everyone read your mail. > This is definately one of those times where the apache lazy concensus works. > > "Hi I'm adding this file to profiles/ for reason X in three days if no one > has > any issues with it." > > Thats really all I'd like to see. Something documented...So when I find the > file magically in profiles/ a week later I can be like "Oh, that was due to > mail on -dev" and not be like "hmm who did that" and then cvs log the file > and then have to hunt you down on irc to figure out why it's there. > > Courtesy towards fellow developers, especially when commiting to global > spaces > such as profiles/ is appreciated by all. If you want to see something documented, shouldn't any reasonable commit message be enough? It's much easier to track that down using cvs log than trying to hunt down a random message on -dev, IMHO, because it's more closely tied to the actual change. I'm not really seeing this as a courtesy issue. The whole tree is a global space. Then again, I'm missing context because people have this weird thing about abstractly bringing up issues without discussing the actual problem. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Discussion
Please don't commit files to profiles/ unless it has been discussed previously on this ML. I don't care if your file is insignificant or 'won't affect anything else' or that it's 'completely necessary'. Please discuss it first. You don't have to ask for a vote on it, or make everyone agree with you. You don't even need to wait three weeks to make sure everyone read your mail. This is definately one of those times where the apache lazy concensus works. "Hi I'm adding this file to profiles/ for reason X in three days if no one has any issues with it." Thats really all I'd like to see. Something documented...So when I find the file magically in profiles/ a week later I can be like "Oh, that was due to mail on -dev" and not be like "hmm who did that" and then cvs log the file and then have to hunt you down on irc to figure out why it's there. Courtesy towards fellow developers, especially when commiting to global spaces such as profiles/ is appreciated by all. -Thanks Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion: alternative compatible utilities
On Tue, 2005-06-21 at 14:45 -0400, Aron Griffis wrote: > Azarah wrote:[Sat Jun 18 2005, 07:23:19AM EDT] > > You might however say install all gnuish tools with the 'g' prefix, > > and then install wrapper scripts/stubs into say /usr/bin/gnu/ or > > /bin/gnu/ (with /usr/bin/gnu/find calling gfind, etc), and portage > > just adds this path as the first path to $PATH ... > > > > This should cover the fact that aliases might not work in all cases, > > and is bsd specific implementation. > > That would actually cause a lot of problems because the PATH would be > inherited by configure and/or make. The result is that programs get > GNU tools when they are built, but BSD tools at run-time. I can only > imagine that causing a lot of confusion. > Ahh, right - didn't think about that. Although you realise that the same issues will be present when eselecting something before and after emerge ? Thanks, -- Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Discussion: alternative compatible utilities
On Tuesday 21 June 2005 20:42, Aron Griffis wrote: > In other words, I think you need to do some work in an overlay so that > you can present a real list of affected ebuilds and utilites, rather > than stating that you "don't really know" Well this was just a discussion, no work should really start for now :) > Rather > I want to suggest the next step is a more complete investigation, > rather than committing any changes to the portage tree. That was for sure :) No big change to do before something working is already there.. like we're doing for G/FBSD. > Why is that a long-term goal? What are the advantages/disadvantages > of the eselect method compared to the aliases? Because aliases makes difficult to follow the flow of an ebuild because you read "sed" and but is gsed that's called.. similarly for other tools. Aliases are like #defines into C code.. makes debug harder, very harder. > As Az mentioned, this is really going to be annoying unless all the > sed programs available support -i BSD does, and I think we can make a prerequisite to be used in portage that the system's sed supports -i. The only problem is with the options orders.. sed -i -e expr works, sed -e -i expr or sed -e expr -i doesn't. > I'll re-iterate: I'm not trying to shoot down this idea completely. > I just want to have a general understanding that it's the *right* > option before making treewide changes. That's why we're discussing it :) -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpVXvhqHVbj3.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
Azarah wrote:[Sat Jun 18 2005, 07:23:19AM EDT] > You might however say install all gnuish tools with the 'g' prefix, > and then install wrapper scripts/stubs into say /usr/bin/gnu/ or > /bin/gnu/ (with /usr/bin/gnu/find calling gfind, etc), and portage > just adds this path as the first path to $PATH ... > > This should cover the fact that aliases might not work in all cases, > and is bsd specific implementation. That would actually cause a lot of problems because the PATH would be inherited by configure and/or make. The result is that programs get GNU tools when they are built, but BSD tools at run-time. I can only imagine that causing a lot of confusion. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpZWKlpp3S9M.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
Diego 'Flameeyes' Pettenò wrote:[Fri Jun 17 2005, 10:05:32AM EDT] > On Friday 17 June 2005 04:32, Aron Griffis wrote: > > Before working on a solution to the problem, could we get a more > > complete list of the tools in question? This has come up before but > > the list seems to always end with "etc etc" ;-) > > Because I don't really know how many applications are available in > different flavours.. so that's why we can use eselect so that it can > be adapted "on the fly". I'm not against using eselect to choose between applications, if that is the right answer. I'm against getting started on these changes without having a better idea of the scope and impact of the project. In other words, I think you need to do some work in an overlay so that you can present a real list of affected ebuilds and utilites, rather than stating that you "don't really know" I appreciate that you brought this idea to the list early, before you had done full investigation. I do not want to discourage you. Rather I want to suggest the next step is a more complete investigation, rather than committing any changes to the portage tree. One of the problems we've had with ports in general is that changes are committed in a flurry of activity before careful consideration of the possible alternatives. > > Unless I misunderstand you, I don't like this at all. It means that > > when an ebuild calls "grep" it doesn't have any idea what the > > supported flags are. > > Well about grep we have no misunderstanding... grep is GNU grep also on the > BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. we > condition this using aliases, but the long-term goal is to avoid this. Why is that a long-term goal? What are the advantages/disadvantages of the eselect method compared to the aliases? > > What scripts are you thinking of in this statement? Sometimes > > ./configure checks, not always, and AFAIK most other scripts don't > > check. > > Most of them checks for GNU tools when they need them, for example > there are a few ./configure which, knowing they need GNU make, in > a system where make is BSD and gmake is GNU, launching "make" then > exec gmake to do the actual work. *nod* It's true that the autotools generally work with make programs other than GNU make. I ported Gnome (versions 1.2 and 1.4) to Tru64 once upon a time and used the system-installed make (and compiler) for most of it. I still think it would be nice to have a list of things that will need modification to work with your scheme. Again, this is something that could be culled from an overlay from which you've done a bootstrap and install of a fairly comprehensive system. > > See, it's this "sed stuff is as compatible as possible" thing I don't > > like. You're talking about writing to a standard instead of an > > implementation. That works for a couple of well-defined compiled > > languages, but I don't think it's going to work for shell scripting > > (ebuilds), especially when the reality is that we'd be writing to half > > a dozen different implementations instead of a standard at all... > > See above: when we need GNU sed, we can use gsed. As Az mentioned, this is really going to be annoying unless all the sed programs available support -i I'll re-iterate: I'm not trying to shoot down this idea completely. I just want to have a general understanding that it's the *right* option before making treewide changes. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpsy8TNSPwjF.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
Hi, I am probably going to be top on the bsd camp's 'most hated list' after this, but here goes ... The more I think on Gentoo/, the more I tend to get this picture of a little boy that wants to play with the older boys, but are constantly in tears, as the older boys runs too fast for him, or go places he cannot go. Ok, so its not a perfect visualisation, but sort of gets the point across. Especially in one camp, many of the userland utilities is really substandard (not even talking about supporting the extended features most of us are accustomed to), but the once or twice I asked why not replace it with the gnu versions, I got the answer: *sob*, because we want to use our own *sob*. This might have changed (the substandard quality), but I am sure the need for these guys to use their own utilities have not. Now, this is all dandy and stuff, but I really do not see how this have to influence 90% (if not more) of the rest of Gentoo-land. On Fri, 2005-06-17 at 16:05 +0200, Diego 'Flameeyes' Pettenò wrote: > On Friday 17 June 2005 04:32, Aron Griffis wrote: > > Before working on a solution to the problem, could we get a more > > complete list of the tools in question? This has come up before but > > the list seems to always end with "etc etc" ;-) > Because I don't really know how many applications are available in different > flavours.. so that's why we can use eselect so that it can be adapted "on the > fly". > And I really do not see why for 10% (I am being generous) of users we should make it possible to select which version of find (or whatever) should be called by default. What other version should the majority of us select between anyhow? Install the bsd versions as well?? I really do not see why we should add extra symlinks and extra logic for 90%+ users that will just never use it. > > Unless I misunderstand you, I don't like this at all. It means that > > when an ebuild calls "grep" it doesn't have any idea what the > > supported flags are. > Well about grep we have no misunderstanding... grep is GNU grep also on the > BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. we > condition this using aliases, but the long-term goal is to avoid this. > Great, so just use a 'long term idea that is more bsd specific'. > > So far we've been free to exploit GNU extensions (aka > > reasonable functionality) in ebuilds. I'd hate to see that go away. > Never said it must go away, actually there's no way that it can go away > completely but.. .we can ask *explicitely* for GNU tools in those cases > (using gsed instead of sed just as an example, or gfind instead of find). > So now we have to start replacing all 'might not work on some sed's (or whatever)' with gsed? This really brings the sed-4 transition days with all its gory details back to mind. > > What scripts are you thinking of in this statement? Sometimes > > ./configure checks, not always, and AFAIK most other scripts don't > > check. > Most of them checks for GNU tools when they need them, for example there are > a > few ./configure which, knowing they need GNU make, in a system where make is > BSD and gmake is GNU, launching "make" then exec gmake to do the actual work. > I thought make already installs as 'gmake' on bsd systems ?? > > See, it's this "sed stuff is as compatible as possible" thing I don't > > like. You're talking about writing to a standard instead of an > > implementation. That works for a couple of well-defined compiled > > languages, but I don't think it's going to work for shell scripting > > (ebuilds), especially when the reality is that we'd be writing to half > > a dozen different implementations instead of a standard at all... > See above: when we need GNU sed, we can use gsed. > I might have here (and above) the wrong impression, but I do not think using 'gsed' in ebuilds is the way to go. Just do something bsd specific that always have 'gsed' as 'sed' when emerge is running ?? See below. > > > I don't think that switching to g-prefixed commands for GNU utilities > > is a good answer. We aren't going to be able to push that upstream, > > which means maintaining a lot of patches ourselves. > Upstream usually already have this fixed for BSD system for example. I > haven't > had too much trouble with that before on G/FBSD, for example the only > autotool-created makefile which failed on BSD make was gawk, and that just > because it used $(RM) var directly; most ./configure scripts checks for rm > and creates $(RM) var themselves when make != gmake. > But I am assuming you cannot count on this, and this is why you want this 'eselect abomination' ? See below. > > What you're suggesting would cause a lot of pain for the majority of > > Gentoo develpers, i.e. the ones running GNU/Linux. > As we are now, on G/FBSD we have anyway quite all the GNU utilities (but for > example we don't need tar and about find we can use the BSD's one with > ebuilds. > > Anywa
Re: [gentoo-dev] Discussion: alternative compatible utilities
Aron Griffis wrote: [Thu Jun 16 2005, 09:32:26PM CDT] > I don't think that switching to g-prefixed commands for GNU utilities > is a good answer. We aren't going to be able to push that upstream, > which means maintaining a lot of patches ourselves. Within our own > developer body, we're going to have an impossible task keeping things > compatible since few people have the knowledge required to write > truly cross-platform scripts. The current situation is that portage sets aliases for tar, make, sed, etcetera that point to the appropriate g* commands on the *BSD systems. I have to admit that I'm actually quite content with that system, since it's not at all intrusive to the Linux folks, and it's minimally intrusive for the *BSDs. It does require that all Gentoo systems have a certain set of GNU utilities, but I'm quite willing to live with that requirement. All that said, if I'm completely missing the point please feel free to tell me. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpmlpPXB1W5t.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
On Friday 17 June 2005 04:32, Aron Griffis wrote: > Before working on a solution to the problem, could we get a more > complete list of the tools in question? This has come up before but > the list seems to always end with "etc etc" ;-) Because I don't really know how many applications are available in different flavours.. so that's why we can use eselect so that it can be adapted "on the fly". > Unless I misunderstand you, I don't like this at all. It means that > when an ebuild calls "grep" it doesn't have any idea what the > supported flags are. Well about grep we have no misunderstanding... grep is GNU grep also on the BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. we condition this using aliases, but the long-term goal is to avoid this. > So far we've been free to exploit GNU extensions (aka > reasonable functionality) in ebuilds. I'd hate to see that go away. Never said it must go away, actually there's no way that it can go away completely but.. .we can ask *explicitely* for GNU tools in those cases (using gsed instead of sed just as an example, or gfind instead of find). > What scripts are you thinking of in this statement? Sometimes > ./configure checks, not always, and AFAIK most other scripts don't > check. Most of them checks for GNU tools when they need them, for example there are a few ./configure which, knowing they need GNU make, in a system where make is BSD and gmake is GNU, launching "make" then exec gmake to do the actual work. > See, it's this "sed stuff is as compatible as possible" thing I don't > like. You're talking about writing to a standard instead of an > implementation. That works for a couple of well-defined compiled > languages, but I don't think it's going to work for shell scripting > (ebuilds), especially when the reality is that we'd be writing to half > a dozen different implementations instead of a standard at all... See above: when we need GNU sed, we can use gsed. > I don't think that switching to g-prefixed commands for GNU utilities > is a good answer. We aren't going to be able to push that upstream, > which means maintaining a lot of patches ourselves. Upstream usually already have this fixed for BSD system for example. I haven't had too much trouble with that before on G/FBSD, for example the only autotool-created makefile which failed on BSD make was gawk, and that just because it used $(RM) var directly; most ./configure scripts checks for rm and creates $(RM) var themselves when make != gmake. > What you're suggesting would cause a lot of pain for the majority of > Gentoo develpers, i.e. the ones running GNU/Linux. As we are now, on G/FBSD we have anyway quite all the GNU utilities (but for example we don't need tar and about find we can use the BSD's one with ebuilds. Anyway, as I already had done, I'm here to fix in case something is using the wrong way... after a couple of examples this can be quite simple as for the old gnu-find dependent ebuilds which are now fixed. -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpu8TEdWaiQA.pgp Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
Diego 'Flameeyes' Pettenò wrote:[Thu Jun 16 2005, 01:57:14AM EDT]
> Let me explain: on Gentoo/Linux systems, all the base utilities
> (make, tar, sed, etc etc) are GNUish
Before working on a solution to the problem, could we get a more
complete list of the tools in question? This has come up before but
the list seems to always end with "etc etc" ;-)
> This limits a bit the user because to use other kind of utilities it
> must use aliases and he can't change, for example, the tar used by
> portage or by other scripts.
>
> As eselect's work is proceeding it can be interesting having a way
> to have the base utils install with a prefix (g for GNU stuff, bsd
> for BSD stuff, eventually fbsd/obsd/nbsd if they are different) and
> then having a link to the basename which acn be changed with
> eselect.
Unless I misunderstand you, I don't like this at all. It means that
when an ebuild calls "grep" it doesn't have any idea what the
supported flags are. Writing shell scripts to the lowest common
denominator is incredibly painful; just ask the maintainer of
keychain. So far we've been free to exploit GNU extensions (aka
reasonable functionality) in ebuilds. I'd hate to see that go away.
Personally I'd prefer to see the selection continue to happen at the
user level (via alias or PATH) rather than happening at the system
level via eselect. I'm all for eselect, but not for programmatic
interfaces that only nominally resemble each other.
Btw, this has been "solved" in the commercial UNIXes for SysV versus
BSD utils for a long time. Most of the time SysV utils are installed
in /usr/bin and the BSD utils are installed in /usr/ucb. I'm not
saying we have to follow that pattern exactly, but I like the fact
that /usr/bin/grep is always the same thing (on a given UNIX)
> Most of the scripts which needs a specific syntax (usually GNU
> syntax) already checks for prefixed executables like gmake, gsed and
> so on,
What scripts are you thinking of in this statement? Sometimes
./configure checks, not always, and AFAIK most other scripts don't
check.
> but the main problem is with portage (think of all the make
> DESTDIR="${D} install stuff), also if emake is fixed and sed stuff
> is as compatible as possible.
See, it's this "sed stuff is as compatible as possible" thing I don't
like. You're talking about writing to a standard instead of an
implementation. That works for a couple of well-defined compiled
languages, but I don't think it's going to work for shell scripting
(ebuilds), especially when the reality is that we'd be writing to half
a dozen different implementations instead of a standard at all...
> Having to provide compatibility with such a framework is quite
> difficult at this point because many ebuilds does depend on GNU
> syntax also if not clearly stated, but I hope this can be fixed
> step-by-step using g-prefixed commands (after making sure that all
> systems will have g-prefixed commands). It's not like something is
> going to happen soon, but maybe in the future this can be a good way
> to make sure we expand the abiliy of users to select what they
> really want.
I don't think that switching to g-prefixed commands for GNU utilities
is a good answer. We aren't going to be able to push that upstream,
which means maintaining a lot of patches ourselves. Within our own
developer body, we're going to have an impossible task keeping things
compatible since few people have the knowledge required to write
truly cross-platform scripts.
I know this isn't offering an easy answer for the BSD folks. :-(
What you're suggesting would cause a lot of pain for the majority of
Gentoo develpers, i.e. the ones running GNU/Linux. Let's think it
through very carefully so we understand our options before setting
down this path.
Regards,
Aron
--
Aron Griffis
Gentoo Linux Developer
pgpBd6FuDmvwa.pgp
Description: PGP signature
Re: [gentoo-dev] Discussion: alternative compatible utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don't attempt to ignore the complexity because it sucks and gives you a headache. The complexity of multiple kernels, userlands, arches and platforms exists whether you like it or not. The key being the management of the complexity. Currently the tools perform poorly because it's been primarly GNU userland + Linux kernel + random arches. The first two are easy to take care of and the third has arch teams. Thus we probably need more keywords ( x86-fbsd-bsd...etc it's been said before ) and we need more people to keyword stuff ( arch-kernel-userland ). I think the big issue is to adapt to the new requirements without making the current tools an overpatched mess. Part of the issue I see is everyone is only focused on their little problem. X, Y or Z that I need is broken and I need fix foo; it's talked about on IRC, it seems to work, it's implemented. Then a week later someone who wasn't on at time of discussion notes that it broke something and and now needs to be 'fixed'. I think Flameeyes has done a pretty good job keeping everyone informed of Gentoo/fbsd's needs and offering pretty good solutions on how to fix them in a general way. I think part of the problem is that this doesn't happen often enough and we end up with a bunch of hacks that need to be integrated together. - -Alec Warner Ajec Dan Meltzer wrote: >Well it would be nice to have it all abstracted, wouldn't stablizing a >package get exponetially harder? Not only would each arch need to be >tested, each combination of packages on each arch would need to be >tested, if FEX openpam became usable on linux instead of just >linuxpam, each arch that stableized would now need to say works for >this arch for linuxpam, and works for this arch for openpam, which >would cause lots and lots of keywords mess. > >Or am I misunderstanding your post? > >On 6/16/05, Luca Barbato <[EMAIL PROTECTED]> wrote: > > >>Diego 'Flameeyes' Pettenò wrote: >> >> >> >>>Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar, >>>sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin >>>I don't really know :P >>>This limits a bit the user because to use other kind of utilities it must use >>>aliases and he can't change, for example, the tar used by portage or by other >>>scripts. >>> >>> >>> >>Surely it would be interesting for developer that want to make sure >>their code will build in other userspaces w/out switching os, >>and if that won't be so painful, would worth testing it. >> >>Obviously having it now isn't really needed. Thinking about that when >>committing/updating ebuild would be good. >> >>( still I do hate bsd core utils implementations but that is just my >>opinion =) ) >> >>lu >> >>-- >> >>Luca Barbato >> >>Gentoo/linux Developer Gentoo/PPC Operational Leader >>http://dev.gentoo.org/~lu_zero >> >>-- >>gentoo-dev@gentoo.org mailing list >> >> >> >> > > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQrHuf2zglR5RwbyYAQKz7g//ei85Mupvhm/nLq5FH3re1pKpYhmvREyX bM51xqH4SXNWB1wCrVgHJXs7YV4nTLnl9lpvg+YKElcrCKwc4wqGTdvYWen9L/Is IzmgHzKkkinfrDHQAXLylCy753S/fuiJowSAcg6rW+8sPadJHU3zYjunC4mhXLLL 99drUDDihS+8KljclJgVkP+fPFMqBo4GgtZtwHH/wksbeomWIIrlF90JFO1AZuA+ 2kLrFcriPxe0/9UD4yZYEjgQ649cA3pYDCMoiNtmVLLeIBqvR7qdNP6LnRjhHD/5 d+f6SVADql2zreUZSxxnCTLN+V32ImRE9Mm6zAafQ/B4C+4uxGUkwQYNpPLrWZfd TmMbd0qHFjmZVTSjwhk6L1lWvcro7Bp9o1IUTQzaqUcpcF/zhsgB9Av29svnhJgY oqA9IavcoM6fT+gl1zSaiKoVCdGEGIAIxlwN/ePst5/hmf/AXr76ooAamAcJlKMV Nrb7Q8crdd7usz4QIuNvjcw/39w/sTrXnPCVStNSdvG887vEVGHMJx0WEsXL7vtU aG5abQ/rPmoYF//SUhAbhYPXXmQhWopGwBobx1cwnnbUEdqEaiuTqGW8eYWiVo3y ziULbj5H9oH/k9q0SOtGjfrF7nIUVgp48CfRprSFKsCKFYYdZ5Hj58TmuEoGRTiO 4kDCAXCWK3E= =/Jnb -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion: alternative compatible utilities
Well it would be nice to have it all abstracted, wouldn't stablizing a package get exponetially harder? Not only would each arch need to be tested, each combination of packages on each arch would need to be tested, if FEX openpam became usable on linux instead of just linuxpam, each arch that stableized would now need to say works for this arch for linuxpam, and works for this arch for openpam, which would cause lots and lots of keywords mess. Or am I misunderstanding your post? On 6/16/05, Luca Barbato <[EMAIL PROTECTED]> wrote: > Diego 'Flameeyes' Pettenò wrote: > > > Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar, > > sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on > > Gentoo/Darwin > > I don't really know :P > > This limits a bit the user because to use other kind of utilities it must > > use > > aliases and he can't change, for example, the tar used by portage or by > > other > > scripts. > > > > Surely it would be interesting for developer that want to make sure > their code will build in other userspaces w/out switching os, > and if that won't be so painful, would worth testing it. > > Obviously having it now isn't really needed. Thinking about that when > committing/updating ebuild would be good. > > ( still I do hate bsd core utils implementations but that is just my > opinion =) ) > > lu > > -- > > Luca Barbato > > Gentoo/linux Developer Gentoo/PPC Operational Leader > http://dev.gentoo.org/~lu_zero > > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Discussion: alternative compatible utilities
Diego 'Flameeyes' Pettenò wrote: > Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar, > sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin > I don't really know :P > This limits a bit the user because to use other kind of utilities it must use > aliases and he can't change, for example, the tar used by portage or by other > scripts. > Surely it would be interesting for developer that want to make sure their code will build in other userspaces w/out switching os, and if that won't be so painful, would worth testing it. Obviously having it now isn't really needed. Thinking about that when committing/updating ebuild would be good. ( still I do hate bsd core utils implementations but that is just my opinion =) ) lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Discussion: alternative compatible utilities
As Gentoo/FreeBSD proceeds, I'm trying to abstract as much as I can the
underlying userland.
Thinking of Gentoo/FreeBSD just as a starting point for other porting of
Gentoo's framework on different operating systems (for example the
already-work-in-progress Gentoo/Darwin, the I-don't-know-how's-doing
Gentoo/OpenBSD, and the maybe-someone-will-work-on Gentoo/NetBSD), there's
something I'd really like to see: alternatives for system utilities.
Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar,
sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin
I don't really know :P
This limits a bit the user because to use other kind of utilities it must use
aliases and he can't change, for example, the tar used by portage or by other
scripts.
As eselect's work is proceeding it can be interesting having a way to have the
base utils install with a prefix (g for GNU stuff, bsd for BSD stuff,
eventually fbsd/obsd/nbsd if they are different) and then having a link to
the basename which acn be changed with eselect.
Most of the scripts which needs a specific syntax (usually GNU syntax) already
checks for prefixed executables like gmake, gsed and so on, but the main
problem is with portage (think of all the make DESTDIR="${D} install stuff),
also if emake is fixed and sed stuff is as compatible as possible.
Having to provide compatibility with such a framework is quite difficult at
this point because many ebuilds does depend on GNU syntax also if not clearly
stated, but I hope this can be fixed step-by-step using g-prefixed commands
(after making sure that all systems will have g-prefixed commands).
It's not like something is going to happen soon, but maybe in the future this
can be a good way to make sure we expand the abiliy of users to select what
they really want.
Comments, ideas, and everythign else is welcome, it's a discussion after all.
--
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
http://dev.gentoo.org/~flameeyes/
pgprrQmdXoIq6.pgp
Description: PGP signature
