Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-wireless/hostapd: ChangeLog hostapd-0.4.9.ebuild hostapd-0.6.1.ebuild hostapd-0.6.0.ebuild
On Dec 11, 2007 6:03 AM, Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 10 December 2007, Donnie Berkholz wrote:
{
...
echo CONFIG_EAP_SAKE=y
...
} ${CONFIG}
cat -EOF ${CONFIG}
...
CONFIG_EAP_SAKE=y
...
EOF
-mike
Mike,
Is what you are suggesting better ? If so, why ?
Denis, clueless.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Handling branch strings
On Mon, 10 Dec 2007 11:42:38 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: You've made these assertions about confusion and breakage, and I would like to understand the reasoning behind them. I don't understand how it would be different than any other SLOT, because they're already a string. USE_EXPAND doesn't allow for the possibility of multiple SLOTs installed at once, which is a feature I would like. Conceptually a branch is not a slot (nor is it a version). Reusing an existing package manager concept for a second, unrelated concept leads to excessively complicated handling rules and a general nasty mess. If there's desire for the package manager to be aware of branches, it should be a separate proposal using a concept specifically designed for that purpose. Branches exist without SCM, and SCM exists without branches, and neither have anything to do with slots or use flags. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] How to pass list of paths to eclass?
Hello.
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
...
done
The problem with this doesn't work if path{1,2} contain spaces. The
solution I'm thinking about is to you arrays:
FONT_CONF=(path1 path2)
for conffile in [EMAIL PROTECTED]; do
...
done
But is this good idea? Are there better?
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
[gentoo-dev] Re: [GLEP] scm package version suffix
Nirbheek Chauhan [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Dec 2007 01:14:06 +0530: On Dec 10, 2007 8:44 PM, Robert Buchholz [EMAIL PROTECTED] wrote: That would still mean everything relies on n ebuilds with mutual blocks. Even if that would work and it block upgrades, it is still not a solution in terms of how to display a list of ebuilds in one tree in an ordered list. The mutual blocks can be via the very nature of the name of the ebuild (ie, the scm_bbranch), and not via unmaintainable dep blocks in the ebuilds. But what about when there's a dependency on any of several branches? That gets hard to maintain if there are multiple ebuilds with similar dependencies. However, that's where virtuals come in. Create a single virtual, depend on it, and you have a single dependency instead of a whole complex list to maintain in all the various depending ebuilds. Another alternative of course is an eclass, inherited by whatever otherwise depending ebuilds, that manages all the dependencies and blockages all in one spot. Which just means there are existing solutions for that angle, so it's out of scope for this GLEP. -- 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-wireless/hostapd: ChangeLog hostapd-0.4.9.ebuild hostapd-0.6.1.ebuild hostapd-0.6.0.ebuild
On Tuesday 11 December 2007, Denis Dupeyron wrote:
On Dec 11, 2007 6:03 AM, Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 10 December 2007, Donnie Berkholz wrote:
{
...
echo CONFIG_EAP_SAKE=y
...
} ${CONFIG}
cat -EOF ${CONFIG}
...
CONFIG_EAP_SAKE=y
...
EOF
Is what you are suggesting better ? If so, why ?
no scoping/subshells and obvious break between content (the stuff between EOF)
and the commands to get it in there (no echos, just one cat)
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] How to pass list of paths to eclass?
On Dec 11, 2007 8:17 AM, Peter Volkov [EMAIL PROTECTED] wrote:
Hello.
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
...
done
The problem with this doesn't work if path{1,2} contain spaces. The
solution I'm thinking about is to you arrays:
FONT_CONF=(path1 path2)
for conffile in [EMAIL PROTECTED]; do
...
done
But is this good idea? Are there better?
--
Peter.
I agree using arrays would be much better, you can also loop through the
arrays like.
for ((i=0;i${#FONT_CONF[*]};i++)); do echo ${FONT_CONF[i]}; done
this way you can avoid spacing because you'll just be calling each array
element in order using quotes.
Fernando
Re: [gentoo-dev] How to pass list of paths to eclass?
On 11:17 Tue 11 Dec , Peter Volkov wrote: FONT_CONF=(path1 path2) for conffile in [EMAIL PROTECTED]; do ... done But is this good idea? Are there better? Roy solved a similar problem in baselayout-2 using hardcoded newlines, although it had the additional constraint of sh compatibility. It's worth considering code clarity between that and arrays. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
On Tuesday 11 December 2007 08:17:12 Peter Volkov wrote:
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
...
done
The problem with this doesn't work if path{1,2} contain spaces. The
solution I'm thinking about is to you arrays:
FONT_CONF=(path1 path2)
for conffile in [EMAIL PROTECTED]; do
...
done
But is this good idea? Are there better?
FONT_CONF=path1:path2
IFS=.
for for conffile in ${FONT_CONF}; do
done
unset IFS
Or if you want to be really picky about preserving IFS if you can't make it
local in a function
SIFS=${IFS-y} OIFS=${IFS}
IFS=.
for for conffile in ${FONT_CONF}; do
done
if [ ${SIFS} = y ]; then
unset IFS
else
IFS=${OIFS}
fi
That way you work the same way as the classic $PATH variable.
But of course no one cares as it's Just Not Bash (tm)
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
On Tuesday 11 December 2007 08:44:51 Donnie Berkholz wrote: Roy solved a similar problem in baselayout-2 using hardcoded newlines, although it had the additional constraint of sh compatibility. It's worth considering code clarity between that and arrays. Only because some commands could litterally have any character in then, making things a little tricky. Here I see no reason why it cannot behave like $PATH and operate under the same constraints. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] scm package version suffix
On Dec 11, 2007 5:57 AM, Steve Long [EMAIL PROTECTED] wrote:
I don't find the argument for versioning the scm live ebuild compelling.
The point wrt comparison, ie foo-1-scm is 2.0.1, doesn't seem enough; it'd
be better to slot that imo, and have a slot identifier[1] in the existing
cvs digit space. You could still have gtk-1-cvs, for example, for packages
where slots don't work.
Versioning for scm live ebuilds can be useful when you know which
version the branch will be merged in. For example, if you have a
branch awesome-feature and you know it will be merged in 2.5, you
could call the ebuild app-misc/blah-2.4-scm_bawesome-feature so that
it will have higher priority over all versions of the package till 2.5
(if we're not doing mutual blocking for versioned branches). In this
case, you'd have automatic upgrading to 2.5 which can be very
desirable if you have lots of such branches to maintain.
I prefer the way it works now; SLOT and cvs compares later than any other
version in the same slot. (I agree the name is misleading and prefer vcs
since it collides less than other options.)
foo-vcs-rN# standard vcs (i prefer the explicit 0 of current spec)
foo-vcsN-rN # slotted pkg
Why not keep slotting the way it is now via the SLOT variable? What
you're suggesting is pkg-scm${SLOT} which can break if you have string
slots, since then pkg-scm${SLOT} could very well be the name of some
other package, say pkg-scmomg.
foo-vcs_branch_FOO-rN # branch
Hmmm, I prefer foo-scm_b${BRANCHNAME} it keeps the versioning conciser..
foo-vcsN_branch_STRING-rN
..make sense[2] and cover all the use cases that I have read about so far.
It'd be useful to restrict the STRING to a simple upper case ID with a
length limit; the ebuild description will give more information to a user
I don't see why there should be a technical length limit to the
STRING. I say it should just use the name of the branch. This way we
can just have one place to get the branch name from (making them
similar to versions this way).
If a branch name is too large (upto the maintainer's discretion), he
can always use something like MY_BRANCH=${REALLY_LONG_BRANCH_NAME}
inside the ebuild and use something else for the ebuild's name.
A numeric slot id with different branches applying to the same slot would
seem to be enough to track any project over its lifecycle. The id would
only be visible to users choosing to install a live ebuild when the package
is slotted.
While it's true that branches will usually not carry over between
slots, I don't see why we have to restrict them to order purely on the
basis of slots.
- If the package has multiple slots, and a branch only applies to one
of them, the ebuild can just use the SLOT variable to restrict it to
that slot.
- If the branch will be merged by version 2.5, version the branch
ebuild as foo-2.4-scm_b${B}
- If ETA for merging is unknown, foo-scm_b${B}
The reason I don't think it's a good idea to allow full versioning is that
it seems to be clouding the issue. Packages are available, in slots. If the
I don't understand how it's clouding the issue, the versioning system
seems simple enough. Perhaps I'm missing something? Could you please
elaborate?
user chooses version control, it applies to the slot:pkg combination, and
beyond that only needs a mechanism to choose which branch to track.
Maintainers need to track ebuild revisions, and all of us, including
package managers, can do with keeping things simple, imo.
[1] Since SLOT is one of the most basic items in an ebuild, it's something
any user making an ebuild is aware of. A vcs ebuild-writer should have no
problem finding a suitable id, especially if it is to go into the tree.
[2] s/vcs/whatever acronym you prefer/
-vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
-rN if missing, is implicit -r0 (compares before explicit)
--
~Nirbheek Chauhan
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] scm package version suffix
On Dec 11, 2007 1:51 PM, Duncan [EMAIL PROTECTED] wrote: But what about when there's a dependency on any of several branches? That gets hard to maintain if there are multiple ebuilds with similar dependencies. How does it become hard to maintain? Different branch ebuilds are still the same package. For example: app-misc/foo-1.2 depends on app-misc/bar branches won't show up in an upgrade, but you can remove app-misc/bar, do an `emerge --oneshot =app-misc/bar-scm_bfeature` and app-misc/foo's dependency will be satisfied. The idea is that no one would want to automatically upgrade to a branch (because you cannot define upgrade for branches), so make it manual. -- ~Nirbheek Chauhan -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
В Втр, 11/12/2007 в 10:38 +, Roy Marples пишет:
FONT_CONF=path1:path2
IFS=.
IIUC should be IFS=:
for for conffile in ${FONT_CONF}; do
done
unset IFS
That way you work the same way as the classic $PATH variable.
But this seems to fail if we have ':' inside path{1,2}. Is that true?
For PATH the same question stands, but I think that ':' is used there
for historical reasons.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Re: [GLEP] scm package version suffix
On Tue, 11 Dec 2007 16:36:51 +0530 Nirbheek Chauhan [EMAIL PROTECTED] wrote: The idea is that no one would want to automatically upgrade to a branch (because you cannot define upgrade for branches), so make it manual. ...and this is why branches shouldn't be treated like versions. They have their own set of rules and expected behaviours that are best dealt with by a different proposal. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] scm package version suffix
On Dec 11, 2007 5:57 AM, Steve Long [EMAIL PROTECTED] wrote:
I don't find the argument for versioning the scm live ebuild compelling.
The point wrt comparison, ie foo-1-scm is 2.0.1, doesn't seem enough; it'd
be better to slot that imo, and have a slot identifier[1] in the existing
cvs digit space. You could still have gtk-1-cvs, for example, for packages
where slots don't work.
Versioning for scm live ebuilds can be useful when you know which
version the branch will be merged in. For example, if you have a
branch awesome-feature and you know it will be merged in 2.5, you
could call the ebuild app-misc/blah-2.4-scm_bawesome-feature so that
it will have higher priority over all versions of the package till 2.5
(if we're not doing mutual blocking for versioned branches). In this
case, you'd have automatic upgrading to 2.5 which can be very
desirable if you have lots of such branches to maintain.
I prefer the way it works now; SLOT and cvs compares later than any other
version in the same slot. (I agree the name is misleading and prefer vcs
since it collides less than other options.)
foo-vcs-rN# standard vcs (i prefer the explicit 0 of current spec)
foo-vcsN-rN # slotted pkg
Why not keep slotting the way it is now via the SLOT variable? What
you're suggesting is pkg-scm${SLOT} which can break if you have string
slots, since then pkg-scm${SLOT} could very well be the name of some
other package, say pkg-scmomg.
foo-vcs_branch_FOO-rN # branch
Hmmm, I prefer foo-scm_b${BRANCHNAME} it keeps the versioning conciser..
foo-vcsN_branch_STRING-rN
..make sense[2] and cover all the use cases that I have read about so far.
It'd be useful to restrict the STRING to a simple upper case ID with a
length limit; the ebuild description will give more information to a user
I don't see why there should be a technical length limit to the
STRING. I say it should just use the name of the branch. This way we
can just have one place to get the branch name from (making them
similar to versions this way).
If a branch name is too large (upto the maintainer's discretion), he
can always use something like MY_BRANCH=${REALLY_LONG_BRANCH_NAME}
inside the ebuild and use something else for the ebuild's name.
A numeric slot id with different branches applying to the same slot would
seem to be enough to track any project over its lifecycle. The id would
only be visible to users choosing to install a live ebuild when the package
is slotted.
While it's true that branches will usually not carry over between
slots, I don't see why we have to restrict them to order purely on the
basis of slots.
- If the package has multiple slots, and a branch only applies to one
of them, the ebuild can just use the SLOT variable to restrict it to
that slot.
- If the branch will be merged by version 2.5, version the branch
ebuild as foo-2.4-scm_b${B}
- If ETA for merging is unknown, foo-scm_b${B}
The reason I don't think it's a good idea to allow full versioning is that
it seems to be clouding the issue. Packages are available, in slots. If the
I don't understand how it's clouding the issue, the versioning system
seems simple enough. Perhaps I'm missing something? Could you please
elaborate?
user chooses version control, it applies to the slot:pkg combination, and
beyond that only needs a mechanism to choose which branch to track.
Maintainers need to track ebuild revisions, and all of us, including
package managers, can do with keeping things simple, imo.
[1] Since SLOT is one of the most basic items in an ebuild, it's something
any user making an ebuild is aware of. A vcs ebuild-writer should have no
problem finding a suitable id, especially if it is to go into the tree.
[2] s/vcs/whatever acronym you prefer/
-vcsN* and -rN+ (or -r0N+.N+ for prefix portage) in regex terms
-rN if missing, is implicit -r0 (compares before explicit)
--
~Nirbheek Chauhan
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] How to pass list of paths to eclass?
On Tuesday 11 December 2007 11:14:49 Peter Volkov wrote:
That way you work the same way as the classic $PATH variable.
But this seems to fail if we have ':' inside path{1,2}. Is that true?
For PATH the same question stands, but I think that ':' is used there
for historical reasons.
Yes, that does mean you cannot use : in PATH.
I don't actually know if shells allow it to be escaped, but I do know that
escaping does not work when IFS is concerned.
You could also use the embedded newline approach that Donnie mentioned
earlier, but you may or may not want to go there. It's it's fairly ugly code.
But the good news is you can now escape anything into an item, and remian
shell portable. Here's a code snippet
FONT_CONF=conf1
conf2
SIFS=${IFS-y} OIFS=${IFS}
IFS=
for for conffile in ${FONT_CONF}; do
done
if [ ${SIFS} = y ]; then
unset IFS
else
IFS=${OIFS}
fi
Oddly enough, you do need to quote variable assignment now as in my test even
bash got it wrong. Probably a bug, but heh.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Handling branch strings
On Dec 11, 2007 9:11 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 10 Dec 2007 11:42:38 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: You've made these assertions about confusion and breakage, and I would like to understand the reasoning behind them. [...] For my reasoning... just read Ciaran's reply ;-) -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] scm package version suffix
On Dec 11, 2007 4:47 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 11 Dec 2007 16:36:51 +0530 Nirbheek Chauhan [EMAIL PROTECTED] wrote: The idea is that no one would want to automatically upgrade to a branch (because you cannot define upgrade for branches), so make it manual. ...and this is why branches shouldn't be treated like versions. They have their own set of rules and expected behaviours that are best dealt with by a different proposal. I made that statement in the context of unversioned branches where you do not know when the branch will be merged. In the case where you do know when the branch will be merged, the versioned branch ebuild can easily be included in the upgrade list via it's version. So, you cannot upgrade to app-misc/foo-scm_bblah but you *can* upgrade from app-misc/foo-1.2 to app-misc/foo-1.2-scm_bblahblah and then finally upgrade to app-misc/foo-1.3 when the branch gets merged. -- ~Nirbheek Chauhan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Handling branch strings
Donnie Berkholz [EMAIL PROTECTED]: While we're getting a bit off the original topic here, it occurred to me that using SLOTs for this, in combination with various SLOT deps and SLOT blockers, might work. Then one could use a search tool that would display SLOTs to show you which branch you're getting. $ grep SLOT\= *.ebuild emacs-18.59-r4.ebuild:SLOT=18 emacs-21.4-r14.ebuild:SLOT=21 emacs-22.1-r3.ebuild:SLOT=22 $ grep SLOT\= *.ebuild emacs-cvs-22.1.50-r2.ebuild:SLOT=22 emacs-cvs-23.0.50-r1.ebuild:SLOT=23 emacs-cvs-23.0.60-r1.ebuild:SLOT=23-unicode That's how we solved it for GNU Emacs...but we had to tackle file collisions for a while, but now you can have all versions side by side. Branches are easily distinguished by version numbers in upstream's repository, but Emacs may be a special case. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: Hello, I want to make gnupg-2 stable. The problem is that gnupg-1.9 was slotted as slot 1.9 and made stable. So now we have two slots, slot 0 and slot 1.9. gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. As far as I see, there are two migration pathes I can use: 1. Mark gnupg-2 stable, as it blocks older versions, this results in forcing users to manually unmerge the gnugp-1.9 series, this is the quickest and simplest migration path. Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather than SLOT 1.9? he end result would be one slot... If I need to chose 1.9 or 0, I prefer the standard is to have slot 0. 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. I can imagine this resulting in very weird issues, when you have two of the same package installed in the same slot. What? These are two versions If nobody else address this, I will chose the easy way - option#0. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] EAPI placement
Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. Cardoe did we decide where EAPI goes in an ebuild? zmedico yes, just above the inherit zmedico that's the safest and simplest thing to do, anyway Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 zmedico then the eclass would override the EAPI zmedico which probably isn't what you want zmedico are there any eclasses defining EAPI now? I hope not. :) * lavajoe has quit (Leaving) Cardoe I'm not sure zlin not in gentoo-x86 Cardoe but I think it would be something that would happen in the future Cardoe if an eclass uses features that require a specific EAPI Cardoe wouldn't it make sense to list that in there? zlin the kde4 eclasses in the kde4-experimental overlay set eapi=1. zmedico it's fine to do that, it's just too early to do that on lots of eclasses in the main tree, because EAPI=1 is too new zmedico we don't even have stages with EAPI=1 aware portage in them released yet zlin it probably shouldn't ever be done in an existing eclass. Cardoe I think putting EAPI above inherit is bad Cardoe because you're relying on the ebuild author to audit all the eclass code to know which EAPI version is required Cardoe for all the code zmedico same thing if you put it below, no? Cardoe no Cardoe because the eclass code should get executed at EAPI=1 Cardoe while the ebuild could get executed at EAPI=2 zmedico well, people can hash this stuff out over time zmedico there's no rush zmedico with =portage-2.1.4 we can make incompatible changes to eclasses :) Cardoe ok but you see what I'm saying? Cardoe it should go *AFTER* inherit zmedico to me, mixing code intended for multiple EAPIs is messy zmedico it's conceivable to have 2 different EAPIs where it's not even possible Cardoe While it might be messy, I can guarantee it will happen. Cardoe eutils might go to eapi=2 and some ebuild might need eapi=3, but eutils isn't ported to eapi=3 yet. Cardoe If you allow our developers to do it, it will happen. Cardoe Plain and simple. Unless repoman blocks this. zmedico we'll have some rules Cardoe Ok. Let's establish them. Cardoe releasing features and saying eh.. we'll figure it out as we go won't work Cardoe because you're gonna find people are going to stick stuff all over the place from the get go unless there are formal rules now zmedico 1) don't do anything stupid without discussing it with the community first ;) Cardoe well, we tried to talk about it on the mailing list but didn't get a solid answer. Cardoe I'm starting a new thread, and including this convo. Cardoe that's a too lose rule, people break that on a daily basis in the tree. Cardoe Let's address the issue now, rather then having a broken tree 3 months from now that will require 500 commits to fix. Cardoe I'll just send this to the ML now. discuss. -- Doug Klima Gentoo Developer -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 22:49 Tue 11 Dec , Alon Bar-Lev wrote: On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather than SLOT 1.9? he end result would be one slot... If I need to chose 1.9 or 0, I prefer the standard is to have slot 0. What happens to people who only have slot 1.9 installed and not slot 0, or vice versa? You might want to test a few different upgrade scenarios to see what portage does. 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. I can imagine this resulting in very weird issues, when you have two of the same package installed in the same slot. What? These are two versions Right, but two versions are never supposed to be installed into the same slot. They are during upgrade/downgrade, but that's short-term. Some package managers could respond oddly. If you were going to go this route, it would again be worth testing in advance. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: EAPI placement
Doug Klima schrieb: Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] EAPI placement
On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. The only sane solution I can think of is that eclasses shouldn't be allowed to change EAPI, but use conditionals to behave differently if needed. Mixing two (or more) different arbitrary EAPIs isn't going to work as after the inital parsing package managers will only see the last EAPI value anyway. Also there is no guarantee that future EAPI versions will be backwards compatible, so if eclasses could have an EAPI version it would eventually require that all packages using it need the same EAPI version (similar for nested inheritance). It's trivial to let inherit check that an eclass doesn't modify EAPI, and adding the conditional code to eclasses isn't difficult either: foo.eclass: if [ -z $EAPI ]; then inherit foo-eapi0 fi case $EAPI in 0) inherit foo-eapi0 ;; 1|2) inherit foo-eapi1_2 ;; *) eerror foo.eclass: unsupported EAPI value $EAPI ;; esac # EAPI independent code here Obviously instead of specific eclasses one could also inline the relevant code. The only two issues I see in this concept are the eventual multiplication of eclasses and the lack of proper error handling for unsupported EAPIs. Marius PS: Yes, this idea has been mentioned in the old thread as well -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: EAPI placement
On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote: Doug Klima schrieb: Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but you need to use say X feature(which is in EAPI 2). By what you said, this would prevent the ebuild from using the features in EAPI 2. It also isn't smart to bump eclasses' EAPI--EAPI should be set to the lowest common denominator that that feature being used is in. If that made sense ;) -- 2.6.23-gentoo-r3 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: EAPI placement
Thomas Anderson wrote: On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote: Doug Klima schrieb: Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but you need to use say X feature(which is in EAPI 2). By what you said, this would prevent the ebuild from using the features in EAPI 2. It also isn't smart to bump eclasses' EAPI--EAPI should be set to the lowest common denominator that that feature being used is in. If that made sense ;) The issue additionally is that future EAPIs may remove deprecated features and may also have conflicting actions. So running an ebuild that's designed for say EAPI=2, which conflicts with EAPI=1, as EAPI=1 may be broken. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Marius Mauch wrote: On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: Since it doesn't appear the question was answered by the last thread. I'm starting a new thread. The only sane solution I can think of is that eclasses shouldn't be allowed to change EAPI, but use conditionals to behave differently if needed. Mixing two (or more) different arbitrary EAPIs isn't going to work as after the inital parsing package managers will only see the last EAPI value anyway. Also there is no guarantee that future EAPI versions will be backwards compatible, so if eclasses could have an EAPI version it would eventually require that all packages using it need the same EAPI version (similar for nested inheritance). It's trivial to let inherit check that an eclass doesn't modify EAPI, and adding the conditional code to eclasses isn't difficult either: foo.eclass: if [ -z $EAPI ]; then inherit foo-eapi0 fi case $EAPI in 0) inherit foo-eapi0 ;; 1|2) inherit foo-eapi1_2 ;; *) eerror foo.eclass: unsupported EAPI value $EAPI ;; esac # EAPI independent code here Obviously instead of specific eclasses one could also inline the relevant code. The only two issues I see in this concept are the eventual multiplication of eclasses and the lack of proper error handling for unsupported EAPIs. Marius PS: Yes, this idea has been mentioned in the old thread as well This again leads to in a sense, code duplication due to the fact that you have to have several different versions of the code for each EAPI. When you could simply have $pkg_manager execute an eclass as 1 EAPI, another eclass as another and the ebuild as a third EAPI and simplify it for the eclass maintenance. -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: How to pass list of paths to eclass?
Peter Volkov wrote:
Some eclasses (kernel-2, font) use variable to pass space separated PATH
to patch or fontconfig files from ebuild to eclass. In ebuild we use:
FONT_CONF=path1 path2
Then eclasses use the variable:
for conffile in ${FONT_CONF}; do
...
done
The problem with this doesn't work if path{1,2} contain spaces. The
solution I'm thinking about is to you arrays:
FONT_CONF=(path1 path2)
for conffile in [EMAIL PROTECTED]; do
...
done
But is this good idea? Are there better?
I was also thinking about changing it to a function instead of a variable,
so ebuilds would do something like:
dofontconfig ${FILESDIR}/50-myconfig ${FILESDIR}/51-myotherconfig
dofontconfig() {
insinto /etc/fonts/conf.avail/
for conf in $@; do
[[ -e ${conf} ]] doins ${conf}
done
}
course this would require a bit of ebuild editing. not many ebuilds
use FONT_CONF though.
on the other hand, the nicety of the variable is that font ebuilds
rarely need to contain a src_install.
--
looks like christmas at fifty-five degrees
this latitude weakens my knees
EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662)
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote: gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. Drop in according to YOU, which I have taken issue with since 1/1/07. Per last upstream release, and every one since 2.x was release, just as I have quoted and stated many times before. http://lists.gnupg.org/pipermail/gnupg-announce/2007q3/000259.html GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. As far as I see, there are two migration pathes I can use: There is a third you have refused for almost a year now. 1.x should remain slot 0, 2.x should be slot 2. http://bugs.gentoo.org/show_bug.cgi?id=159623 I also mentioned that if left unaddressed I would challenge this issue when it came time for stabilization. Which gnupg2 was release over a year ago now. Main reason that held it back so long was refusal to slot 2.x versions, in any slot other than 0. Just as 1.9 was slotted. Even if all technical issues with gnupg 2.x have been worked out. It is NOT a drop in replacement for 1.x. The two are different and DESIGNED to work together. We will effectively rob users of the choice of 1.x for what ever reasons and force 2.x on them. Which deviates from all other distros. Not to mention we symlink gpg - gpg2, and gpg2 does not implement all features of gpg, command line args. By default upstream spits out the binaries on build with different names, same thing with .so's and etc. So there isn't any conflict/collision problems. In fact just the opposite if one hits gpg expecting a gpg command feature set, and instead getting a gpg2 one. I have wasted weeks on this posting on comments on bugs. Brought up the issue here before. We have lost a year wrt to gnupg 2. I am all for moving forward and dropping legacy versions of packages from the tree. But this is not one IMHO. Last post on this topic, ever for me. It's WAY stupid at this point. The horse has been beaten to death, exhumed, killed again, re-exhumed, mummified, put on exhibit, taken down, killed again, and re-buried :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, Donnie Berkholz [EMAIL PROTECTED] wrote: On 22:49 Tue 11 Dec , Alon Bar-Lev wrote: On Dec 9, 2007 9:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: On 15:49 Sat 08 Dec , Alon Bar-Lev wrote: Seems reasonable. Any particular reason to slot gnupg-2 as SLOT 0 rather than SLOT 1.9? he end result would be one slot... If I need to chose 1.9 or 0, I prefer the standard is to have slot 0. What happens to people who only have slot 1.9 installed and not slot 0, or vice versa? You might want to test a few different upgrade scenarios to see what portage does. OK, I will try this. 2. Perform slot-move of slot 0 and slot 1.9 into slot 2, so migration will be smooth. The problem is that I need all archs to work with me in timely manner so that this will be possible. I have bug#194113 waiting for arm, mips, s390, sh, and this only for the dependencies. I can imagine this resulting in very weird issues, when you have two of the same package installed in the same slot. What? These are two versions Right, but two versions are never supposed to be installed into the same slot. They are during upgrade/downgrade, but that's short-term. Some package managers could respond oddly. If you were going to go this route, it would again be worth testing in advance. I don't understand... It works quite some time for many people. Alon. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On 12/12/07, William L. Thomson Jr. [EMAIL PROTECTED] wrote: On Sat, 2007-12-08 at 15:49 +0200, Alon Bar-Lev wrote: gnupg-2 is drop-in replacement of gnupg-1, so eventually no slotting should be used. Drop in according to YOU, which I have taken issue with since 1/1/07. Per last upstream release, and every one since 2.x was release, just as I have quoted and stated many times before. http://lists.gnupg.org/pipermail/gnupg-announce/2007q3/000259.html GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. As I told you before, I wont slot these two. Best Regards, Alon Bar-Lev. -- [EMAIL PROTECTED] mailing list
