Re: [gentoo-dev] mercurial.eclass: change clone destination
On 21:30 Sat 06 Nov , Donnie Berkholz wrote:
> On 10:22 Sat 06 Nov , Krzysztof Pawlik wrote:
> > I'm sending this patch for discussion, what it changes? The change is
> > to where the final clone of repository will be placed, it used to be
> > ${WORKDIR}/${module} (where module usually is the last component of
> > source URI) to ${WORKDIR}/${P} (essentially ${S}). This has few
> > effects:
> > - ebuilds using mercurial.eclass don't need to set S any longer
> > - mercurial.eclass behaves more like git.eclass
> > - it breaks all existing ebuilds using this eclass
> >
> > The last effect is really, really nasty :( At the same time I think
> > it's worth fixing this now, not when we have even more ebuilds using
> > mercurial.eclass. Thankfully the fix to this is trivial: just remove
> > the line where S is being set (or adjust it to match as is in case of
> > one ebuild in the tree).
>
> Krzysztof,
>
> I see you've said you're breaking all these ebuilds but I don't see any
> rationale for the change, at least in this email. Perhaps you could
> explain why this level of breakage is necessary?
I read it more closely and realized I was a little confused by the way
you listed all the bullet points mixing together benefits and problems.
So I'll try again: if you really want to do this change, you might want
to consider adding a mercurial-2.eclass instead. Eclasses of this nature
(svn, git, hg, etc) tend to be broadly used outside the tree as well as
within, so breaking backwards compatibility can be a real problem. A new
versioned eclass allows for a much more gradual transition.
--
Thanks,
Donnie
Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpcrj1QRw1zN.pgp
Description: PGP signature
Re: [gentoo-dev] mercurial.eclass: change clone destination
On 10:22 Sat 06 Nov , Krzysztof Pawlik wrote:
> I'm sending this patch for discussion, what it changes? The change is
> to where the final clone of repository will be placed, it used to be
> ${WORKDIR}/${module} (where module usually is the last component of
> source URI) to ${WORKDIR}/${P} (essentially ${S}). This has few
> effects:
> - ebuilds using mercurial.eclass don't need to set S any longer
> - mercurial.eclass behaves more like git.eclass
> - it breaks all existing ebuilds using this eclass
>
> The last effect is really, really nasty :( At the same time I think
> it's worth fixing this now, not when we have even more ebuilds using
> mercurial.eclass. Thankfully the fix to this is trivial: just remove
> the line where S is being set (or adjust it to match as is in case of
> one ebuild in the tree).
Krzysztof,
I see you've said you're breaking all these ebuilds but I don't see any
rationale for the change, at least in this email. Perhaps you could
explain why this level of breakage is necessary?
--
Thanks,
Donnie
Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com
pgpCuy0qPluWD.pgp
Description: PGP signature
Re: [gentoo-dev] Hardened is planning on restructuring its profiles
On 11/06/2010 11:45 AM, Alex Alexander wrote: > On 6 Nov 2010, at 16:37, "Anthony G. Basile" wrote: > >> >> Hi everyone, >> >> The hardened team is planning to restructure its profiles so that there >> is no version. Thus on a amd64 system, >> >> [8] hardened/linux/amd64/10.0 >> [9] hardened/linux/amd64/10.0/no-multilib >> >> would appear as >> >> [8] hardened/linux/amd64 >> [9] hardened/linux/amd64/no-multilib >> >> We're planning on starting with the minor arches and then moving onto >> x86 and amd64. Since this has the potential to impact all profiles >> (given the complex inheritance structure), we'd like any feedback or >> caveats before we proceed. >> >> Anthony G. Basile (blueness) >> and the hardened team >> >> -- >> Anthony G. Basile, Ph.D. >> Gentoo Developer >> >> > > I'd like to know why you made this decision :) > > also, what will you do in the future if the need to make a change that breaks > stuff shows up? > > Alex | wired | sent from my i4 The idea here is that if the version changes from 10.0 to 12.0 or whatever, then the user doesn't have to change profiles. They can just stay on (say) hardened/linux/amd64 and we'll make the profile change behind the scene by modifying a line like ../../../releases/10.0 to ../../../releases/12.0 -- Anthony G. Basile, Ph.D. Gentoo Developer
Re: [gentoo-dev] RFC: global USE lzma
El sáb, 06-11-2010 a las 17:44 +0100, Tomáš Chvátal escribió: > Dne 6.11.2010 16:49, Pacho Ramos napsal(a): > > El sáb, 06-11-2010 a las 16:12 +0100, justin escribió: > >> HI, > >> > >> has there are no objections I will add it to global as > >> > >> "Support for LZMA/XZ (de)compression algorithm" > >> > >> > >> justin > >> > > > > I would vote for calling that new global USE flag "xz" instead of "lzma" > > since, if I don't misremember, lzma is going to be replaced by xz > > > > Thanks > .xz is file suffix, algorithm is lzmaVERSION. where god knows what > version it is now. Didn't know that, then, lzma looks like the best option. Thanks As a side note, probably sys-fs/avfs would need to rename "xz" local USE flag to "lzma" ;-) Best regards signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: global USE lzma
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 6.11.2010 16:49, Pacho Ramos napsal(a): > El sáb, 06-11-2010 a las 16:12 +0100, justin escribió: >> HI, >> >> has there are no objections I will add it to global as >> >> "Support for LZMA/XZ (de)compression algorithm" >> >> >> justin >> > > I would vote for calling that new global USE flag "xz" instead of "lzma" > since, if I don't misremember, lzma is going to be replaced by xz > > Thanks .xz is file suffix, algorithm is lzmaVERSION. where god knows what version it is now. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzVhdUACgkQHB6c3gNBRYcXtACgpT4M4PXjxaQ5tZ0VumtApjMP ktIAn0LerRCCctGYTqnh5uYINf0ZJEEM =kvH3 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: global USE lzma
On Sat, 06 Nov 2010 16:12:57 +0100 justin wrote: > has there are no objections I will add it to global as > > "Support for LZMA/XZ (de)compression algorithm" XZ is not an algorithm. AFAIK .xz is just a file format using LZMA2. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Hardened is planning on restructuring its profiles
On 11/06/2010 10:46 AM, Theo Chatzimichos wrote: > On Saturday 06 November 2010 16:37:41 Anthony G. Basile wrote: >> Hi everyone, >> >> The hardened team is planning to restructure its profiles so that there >> is no version. Thus on a amd64 system, >> >> [8] hardened/linux/amd64/10.0 >> [9] hardened/linux/amd64/10.0/no-multilib >> >> would appear as >> >> [8] hardened/linux/amd64 >> [9] hardened/linux/amd64/no-multilib >> >> We're planning on starting with the minor arches and then moving onto >> x86 and amd64. Since this has the potential to impact all profiles >> (given the complex inheritance structure), we'd like any feedback or >> caveats before we proceed. >> >> Anthony G. Basile (blueness) >> and the hardened team > > News item please Yes, definitely. We didn't prepare a news item yet because we'd like to hear back from the community first. -- Anthony G. Basile, Ph.D. Gentoo Developer
Re: [gentoo-dev] RFC: global USE lzma
El sáb, 06-11-2010 a las 16:12 +0100, justin escribió: > HI, > > has there are no objections I will add it to global as > > "Support for LZMA/XZ (de)compression algorithm" > > > justin > I would vote for calling that new global USE flag "xz" instead of "lzma" since, if I don't misremember, lzma is going to be replaced by xz Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Hardened is planning on restructuring its profiles
On 6 Nov 2010, at 16:37, "Anthony G. Basile" wrote: > > Hi everyone, > > The hardened team is planning to restructure its profiles so that there > is no version. Thus on a amd64 system, > > [8] hardened/linux/amd64/10.0 > [9] hardened/linux/amd64/10.0/no-multilib > > would appear as > > [8] hardened/linux/amd64 > [9] hardened/linux/amd64/no-multilib > > We're planning on starting with the minor arches and then moving onto > x86 and amd64. Since this has the potential to impact all profiles > (given the complex inheritance structure), we'd like any feedback or > caveats before we proceed. > > Anthony G. Basile (blueness) > and the hardened team > > -- > Anthony G. Basile, Ph.D. > Gentoo Developer > > I'd like to know why you made this decision :) also, what will you do in the future if the need to make a change that breaks stuff shows up? Alex | wired | sent from my i4
Re: [gentoo-dev] RFC: global USE lzma
HI, has there are no objections I will add it to global as "Support for LZMA/XZ (de)compression algorithm" justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Hardened is planning on restructuring its profiles
On Saturday 06 November 2010 16:37:41 Anthony G. Basile wrote: > Hi everyone, > > The hardened team is planning to restructure its profiles so that there > is no version. Thus on a amd64 system, > > [8] hardened/linux/amd64/10.0 > [9] hardened/linux/amd64/10.0/no-multilib > > would appear as > > [8] hardened/linux/amd64 > [9] hardened/linux/amd64/no-multilib > > We're planning on starting with the minor arches and then moving onto > x86 and amd64. Since this has the potential to impact all profiles > (given the complex inheritance structure), we'd like any feedback or > caveats before we proceed. > > Anthony G. Basile (blueness) > and the hardened team News item please -- Theo Chatzimichos (tampakrap) Gentoo KDE/Qt, Planet, Overlays signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Hardened is planning on restructuring its profiles
Hi everyone, The hardened team is planning to restructure its profiles so that there is no version. Thus on a amd64 system, [8] hardened/linux/amd64/10.0 [9] hardened/linux/amd64/10.0/no-multilib would appear as [8] hardened/linux/amd64 [9] hardened/linux/amd64/no-multilib We're planning on starting with the minor arches and then moving onto x86 and amd64. Since this has the potential to impact all profiles (given the complex inheritance structure), we'd like any feedback or caveats before we proceed. Anthony G. Basile (blueness) and the hardened team -- Anthony G. Basile, Ph.D. Gentoo Developer
[gentoo-dev] mercurial.eclass: change clone destination
Hello,
I'm sending this patch for discussion, what it changes? The change is to where
the final clone of repository will be placed, it used to be ${WORKDIR}/${module}
(where module usually is the last component of source URI) to ${WORKDIR}/${P}
(essentially ${S}). This has few effects:
- ebuilds using mercurial.eclass don't need to set S any longer
- mercurial.eclass behaves more like git.eclass
- it breaks all existing ebuilds using this eclass
The last effect is really, really nasty :( At the same time I think it's worth
fixing this now, not when we have even more ebuilds using mercurial.eclass.
Thankfully the fix to this is trivial: just remove the line where S is being set
(or adjust it to match as is in case of one ebuild in the tree).
Following ebuilds in tree use mercurial.eclass:
dev-python/django-piston/django-piston-.ebuild
dev-vcs/mercurial/mercurial-.ebuild
media-radio/radiotray/radiotray-.ebuild
media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r3.ebuild
media-tv/v4l-dvb-hg/v4l-dvb-hg-0.1-r2.ebuild
www-client/dillo/dillo-.ebuild
x11-misc/sselp/sselp-.ebuild
x11-wm/parti/parti-.ebuild
If there are no objections my plan is as follows:
- in a week commit the change to eclass
- fix all above ebuilds
- send a small announcement to gentoo-dev-announcement
Bug: https://bugs.gentoo.org/343993
--
Krzysztof Pawlikkey id: 0xF6A80E46
desktop-misc, java, vim, kernel, python, apache...
Index: mercurial.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v
retrieving revision 1.14
diff -u -r1.14 mercurial.eclass
--- mercurial.eclass26 Oct 2010 19:04:44 - 1.14
+++ mercurial.eclass6 Nov 2010 09:05:37 -
@@ -68,12 +68,14 @@
EHG_OFFLINE="${EHG_OFFLINE:-${ESCM_OFFLINE}}"
# @FUNCTION: mercurial_fetch
-# @USAGE: [repository_uri] [module]
+# @USAGE: [repository_uri] [module] [workdir]
# @DESCRIPTION:
# Clone or update repository.
#
-# If not repository URI is passed it defaults to EHG_REPO_URI, if module is
-# empty it defaults to basename of EHG_REPO_URI.
+# If repository URI is not passed it defaults to EHG_REPO_URI, if module is
+# empty it defaults to basename of EHG_REPO_URI, workdir defaults to P. workdir
+# argument is a directory name under WORKDIR where sources will be available.
If
+# you change workdir note that you will need to adjust S to match.
function mercurial_fetch {
debug-print-function ${FUNCNAME} ${*}
@@ -81,6 +83,7 @@
[[ -z "${EHG_REPO_URI}" ]] && die "EHG_REPO_URI is empty"
local module="${2-$(basename "${EHG_REPO_URI}")}"
+ local workdir="${3-${P}}"
# Should be set but blank to prevent using $HOME/.hgrc
export HGRCPATH=
@@ -116,19 +119,19 @@
fi
# Checkout working copy:
- einfo "Creating working directory in ${WORKDIR}/${module} (target
revision: ${EHG_REVISION})"
+ einfo "Creating working directory in ${WORKDIR}/${workdir} (target
revision: ${EHG_REVISION})"
hg clone \
${EHG_QUIET_CMD_OPT} \
--rev="${EHG_REVISION}" \
"${EHG_STORE_DIR}/${EHG_PROJECT}/${module}" \
- "${WORKDIR}/${module}" || die "hg clone failed"
+ "${WORKDIR}/${workdir}" || die "hg clone failed"
# An exact revision helps a lot for testing purposes, so have some
output...
# id num branch
# fd6e32d61721 6276 default
- local HG_REVDATA=($(hg identify -b -i "${WORKDIR}/${module}"))
+ local HG_REVDATA=($(hg identify -b -i "${WORKDIR}/${workdir}"))
export HG_REV_ID=${HG_REVDATA[0]}
local HG_REV_BRANCH=${HG_REVDATA[1]}
- einfo "Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}"
+ einfo "Work directory: ${WORKDIR}/${workdir} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}"
}
# @FUNCTION: mercurial_src_unpack
signature.asc
Description: OpenPGP digital signature
