[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 30 Mar 2008 20:39:14 -0400: there is no package-manager specificness here. it's already completely doable from a user perspective, just having it in the ebuild makes my life and users' lives easier. i'm using it in packages that tend to have a lot of extraneous patchsets associated with them. the random patches were punted from ebuilds and now it's up to the user to maintain the feature sets. I've been working with upstream, various users, and Dan Rahn from OpenSuSE (who has been absolutely great to work with, especially so since he can do the coding I can't), on glib-2.16 and gcc-4.3 compatibility patches for net-nntp/pan, and something like this would certainly make my life a lot easier. FWIW the Gentoo bugs are 21160 and 214446, with half the story on the pan-user list (which is developer oriented too right now since the stable build is ancient so most users are on the beta releases or SVN). The point here though is that particularly for the glib patch, which has undergone several rounds of testing and looks set for another round or two at least, this user patch infrastructure would sure be nice! -- 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
В Пнд, 31/03/2008 в 06:21 +, Duncan пишет: Mike Frysinger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 30 Mar 2008 20:39:14 -0400: there is no package-manager specificness here. it's already completely doable from a user perspective, just having it in the ebuild makes my life and users' lives easier. i'm using it in packages that tend to have a lot of extraneous patchsets associated with them. the random patches were punted from ebuilds and now it's up to the user to maintain the feature sets. The point here though is that particularly for the glib patch, which has undergone several rounds of testing and looks set for another round or two at least, this user patch infrastructure would sure be nice! It possible to use /etc/portage/bashrc to have this infrastructure. Search mailing list, it was discussed here at least twice, and this is example from solar: http://dev.gentoo.org/~solar/bashrc http://dev.gentoo.org/~solar/portage_misc/bashrc.autopatch There is no need to put such things into ebuild. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
User patches (Was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild)
Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: On Sunday 30 March 2008, Mark Loeser wrote: Actually, I'd say this should just be removed. If a user wants to apply a patch, they can put their own ebuild into an overlay and do it themselves (presumably if they want to patch something, they'll know how to make the simple modifications to an ebuild). By allowing the user to arbitrarily patch something means we have no idea what the user has built and is filing a bug about. If they installed an ebuild from an overlay it is a lot easier to identify what they built. Sure, they could patch the ebuild in their tree, but by supporting user supplied patches easily in this way, we are encouraging them to patch things without our knowledge. If we start supporting this across the board, I can see bugs being filed when their patches break and they don't understand what is happening. that's actually exactly what i'm encouraging. i'm not worried about such issues as they're easily resolved by people posting the full build log. Which is great, but I think this is something we should discuss and figure out if this is something we want to introduce into the tree (too late now, but better late than never). If it is something we want to move forward with, it should be introduced at the package manager level instead of being an in-tree package manager specific feature. I think that maybe we should first introduce new patching phase and then make this user patch really usable feature. For example if you want to patch something that's input to running autotools, doing it in post_src_unpack is too late... Caster -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Peter Volkov [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 31 Mar 2008 14:15:45 +0400: It possible to use /etc/portage/bashrc to have this infrastructure. Search mailing list, it was discussed here at least twice, and this is example from solar: http://dev.gentoo.org/~solar/bashrc http://dev.gentoo.org/~solar/portage_misc/bashrc.autopatch Thanks. -- 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 -- gentoo-dev@lists.gentoo.org mailing list
Re: User patches (Was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild)
On 2008/03/31, Vlastimil Babka [EMAIL PROTECTED] wrote: I think that maybe we should first introduce new patching phase and then make this user patch really usable feature. For example if you want to patch something that's input to running autotools, doing it in post_src_unpack is too late... Not really. I'm using Ed Catmur's bashrc, and his post_src_unpack hook for /etc/portage/patches/ can detect when running autotools is needed: http://sources.catmur.co.uk/viewvc/svn/gentoo/phase_hooks.d/post_src_unpack/portage-patches?view=co http://catmur.co.uk/gentoo/ Sure, this detection (based on what files are modified) may not work in all cases. And when it does, then autotools may fail too (basically wherever an ebuild writer would have needed to do do more than just inherit autotools before running eautofoo). But it's still pretty cool. -- TGL. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Donnie Berkholz [EMAIL PROTECTED] said:
On 17:26 Sat 29 Mar , Mike Frysinger (vapier) wrote:
1.1 sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1content-type=text/plain
local check base=${PORTAGE_CONFIGROOT}/etc/portage/patches
for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}; do
EPATCH_SOURCE=${base}/${CTARGET}/${check}
[[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${base}/${CHOST}/${check}
[[ -r ${EPATCH_SOURCE} ]] || EPATCH_SOURCE=${base}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
EPATCH_SUFFIX=patch
EPATCH_FORCE=yes \
EPATCH_MULTI_MSG=Applying user patches from
${EPATCH_SOURCE} ... \
epatch
break
fi
done
This looks like it should be generic code somewhere else.
Actually, I'd say this should just be removed. If a user wants to apply
a patch, they can put their own ebuild into an overlay and do it
themselves (presumably if they want to patch something, they'll know how
to make the simple modifications to an ebuild). By allowing the user to
arbitrarily patch something means we have no idea what the user has
built and is filing a bug about. If they installed an ebuild from an
overlay it is a lot easier to identify what they built. Sure, they
could patch the ebuild in their tree, but by supporting user supplied
patches easily in this way, we are encouraging them to patch things
without our knowledge. If we start supporting this across the board, I
can see bugs being filed when their patches break and they don't
understand what is happening.
Thanks,
--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
pgp00OFv13uhm.pgp
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Mark Loeser schrieb: Mike Frysinger [EMAIL PROTECTED] said: that's actually exactly what i'm encouraging. i'm not worried about such issues as they're easily resolved by people posting the full build log. Which is great, but I think this is something we should discuss and figure out if this is something we want to introduce into the tree (too late now, but better late than never). If it is something we want to move forward with, it should be introduced at the package manager level instead of being an in-tree package manager specific feature. I'm coming at this from a QA perspective and if we want to do it for one package, it should be introduced for all. We should document it and know how to support it as well. +1 on that, quite a bunch of overlayed ebuilds won't be needed if additional patches could be applied this way. we should just find a way to enable/disable this and make it visible on support requests. Greetz -Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
On Sun, 30 Mar 2008 17:18:44 -0400
Mark Loeser [EMAIL PROTECTED] wrote:
If it is something we want to move forward with, it should be
introduced at the package manager level instead of being an in-tree
package manager specific feature.
cat /etc/paludis/hooks/ebuild_unpack_post/patches.bash
(
einfo Looking for user patches
cd ${S}
patchdir=/etc/paludis/autopatch/${CATEGORY}/${PN}
if [[ -d $patchdir ]] ; then
einfo Applying user patches
for p in $patchdir/*.patch ; do
einfo Applying $(basename ${p} )
patch -p1 ${p} || exit 1
done
einfo Done
fi
)
Not that I'd really encourage its use...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Ciaran McCreesh kirjoitti:
On Sun, 30 Mar 2008 17:18:44 -0400
Mark Loeser [EMAIL PROTECTED] wrote:
If it is something we want to move forward with, it should be
introduced at the package manager level instead of being an in-tree
package manager specific feature.
cat /etc/paludis/hooks/ebuild_unpack_post/patches.bash
(
einfo Looking for user patches
cd ${S}
patchdir=/etc/paludis/autopatch/${CATEGORY}/${PN}
if [[ -d $patchdir ]] ; then
einfo Applying user patches
for p in $patchdir/*.patch ; do
einfo Applying $(basename ${p} )
patch -p1 ${p} || exit 1
done
einfo Done
fi
)
Not that I'd really encourage its use...
A similar hook can be rewritten (and I think solar already has) using
Portage bashrc support so we already have the custom patching support.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
On Sunday 30 March 2008, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: On Sunday 30 March 2008, Mark Loeser wrote: Actually, I'd say this should just be removed. If a user wants to apply a patch, they can put their own ebuild into an overlay and do it themselves (presumably if they want to patch something, they'll know how to make the simple modifications to an ebuild). By allowing the user to arbitrarily patch something means we have no idea what the user has built and is filing a bug about. If they installed an ebuild from an overlay it is a lot easier to identify what they built. Sure, they could patch the ebuild in their tree, but by supporting user supplied patches easily in this way, we are encouraging them to patch things without our knowledge. If we start supporting this across the board, I can see bugs being filed when their patches break and they don't understand what is happening. that's actually exactly what i'm encouraging. i'm not worried about such issues as they're easily resolved by people posting the full build log. Which is great, but I think this is something we should discuss and figure out if this is something we want to introduce into the tree (too late now, but better late than never). If it is something we want to move forward with, it should be introduced at the package manager level instead of being an in-tree package manager specific feature. I'm coming at this from a QA perspective and if we want to do it for one package, it should be introduced for all. We should document it and know how to support it as well. there is no package-manager specificness here. it's already completely doable from a user perspective, just having it in the ebuild makes my life and users' lives easier. i'm using it in packages that tend to have a lot of extraneous patchsets associated with them. the random patches were punted from ebuilds and now it's up to the user to maintain the feature sets. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
On 17:26 Sat 29 Mar , Mike Frysinger (vapier) wrote:
1.1 sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1content-type=text/plain
local check base=${PORTAGE_CONFIGROOT}/etc/portage/patches
for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}; do
EPATCH_SOURCE=${base}/${CTARGET}/${check}
[[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${base}/${CHOST}/${check}
[[ -r ${EPATCH_SOURCE} ]] || EPATCH_SOURCE=${base}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
EPATCH_SUFFIX=patch
EPATCH_FORCE=yes \
EPATCH_MULTI_MSG=Applying user patches from
${EPATCH_SOURCE} ... \
epatch
break
fi
done
This looks like it should be generic code somewhere else.
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
