Re: [gentoo-dev] vcs-snapshot.eclass: add a way to specify the extraction path
Dnia 2015-07-30, o godz. 10:57:46
William Hubbs napisał(a):
> All,
>
> I'm finding in working on Go ebuilds, that we are propegating a
> src_unpack function that is very similar to the one in vcs-snapshot.
>
> This patch adds an EXTRACT_PATH variable to the vcs-snapshot eclass
> which, if set, puts the extracted archives in the specified directory under
> ${S}.
>
> If it is not set, nothing should happen.
>
> This could be used by other types of ebuilds later, but for now it would
> be used by Go ebuilds.
>
> Thoughts?
I'm against it. This doubles the eclass code, adding completely
orthogonal and incompatible behavior.
The goal of this eclass is to provide a relatively simple way of
extracting VCS snapshots and putting them in a predictable locations,
not fitting some random src_unpack() you happen to use.
--
Best regards,
Michał Górny
[gentoo-dev] Last rites: dev-java/jjtraveler
# Patrice Clement (30 Jul 2015) # Broken and upstream dead isn't always a good mix. # Removal in 30 days. See bug #368049. dev-java/jjtraveler
Re: [gentoo-dev] vcs-snapshot.eclass: add a way to specify the extraction path
On Thu, Jul 30, 2015 at 11:57 AM, William Hubbs wrote:
> All,
>
> I'm finding in working on Go ebuilds, that we are propegating a
> src_unpack function that is very similar to the one in vcs-snapshot.
>
> This patch adds an EXTRACT_PATH variable to the vcs-snapshot eclass
> which, if set, puts the extracted archives in the specified directory under
> ${S}.
>
> If it is not set, nothing should happen.
>
> This could be used by other types of ebuilds later, but for now it would
> be used by Go ebuilds.
>
> Thoughts?
Can you provide an example of an ebuild in the tree for which this
would be useful?
I'm unclear as to why tarballs are being unpacked in sub-directories of ${S}.
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
On 30 July 2015 at 19:15, Ian Stakenvicius wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 30/07/15 01:55 AM, Duncan wrote:
> > Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as
> > excerpted:
> >
> >> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev
> >> wrote:
> >>
> >>> On 29 July 2015 at 23:20, William Hubbs
> >>> wrote:
>
> so that there is a better idea out there of what I'm talking
> about, the OpenRC github repository now has a mount-service
> branch.
> >>>
> >>> But I still trying to figure out why do we need to keep fstab
> >>> around. It is pure legacy.
> >>>
> >>>
> >> On what planet is fstab pure legacy? Many utilities use it and
> >> expect it to exist. For example the ability to do "mount /foo"
> >> requires a properly configured fstab file (also mount -a).
> >>
>
> I think there are two meanings of the word legacy here.
>
> #1, /etc/fstab on linux is not legacy, and I don't think anyone here
> (except possibly for WilliamH as I can't actually tell from his
> statements) has been calling it 'legacy' in this context.
/etc/fstab is legacy in the sense it did not evolve since early days of UNIX.
Imagine /etc/crontab was left the same single file, but it at least
evolved to usr /etc/cron.*/ to ease management of multiple sources and
ease packaging/maintenance without need to parse and rewrite single
file when provisioning.
Nobody ignores /etc/fstab existence, I provided solutions of how
/etc/fstab can be read in flexible method as netifrc does (which was
actually the core idea of this move), doing so will make the service
much simpler as it can use external helper scripts to provide the data
out of whatever source, please re-read my message.
However, having the option *NOT* to use /etc/fstab has many advantages
in security (storing credentials in own files), provisioning (no need
to race parse/rewrite), dynamic (define the location of nfs server
based on logic) and many more.
I do not understand why people are so sensitive for a change that does
not effect the outcome of their need, all that I recommended to add is
driver:
mount_driver_\${NAME}=fstab
mount_mountpoint_\${NAME}=/mnt/auto
driver will be executed by the service, in this case:
openrc-mount-helper-${openrc_mount_driver_\${NAME}}
${mount_mountpoint_\${NAME}}
the output will be evaluated. This simple solution will enable the
service to be generic and provide flexible pure configuration
(whatever we choose), while support any source of information that is
capable of constructing this configuration.
Loose nothing gain some, simpler service and constraint fstab within driver.
Another drive I can think of is UPnP.
Regards,
Alon
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/07/15 12:26 PM, William Hubbs wrote: > On Thu, Jul 30, 2015 at 12:15:38PM -0400, Ian Stakenvicius wrote: > On 30/07/15 01:55 AM, Duncan wrote: Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as excerpted: > On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev > wrote: > >> On 29 July 2015 at 23:20, William Hubbs >> wrote: >>> >>> so that there is a better idea out there of what I'm >>> talking about, the OpenRC github repository now has a >>> mount-service branch. >> >> But I still trying to figure out why do we need to keep >> fstab around. It is pure legacy. >> >> > On what planet is fstab pure legacy? Many utilities use it > and expect it to exist. For example the ability to do > "mount /foo" requires a properly configured fstab file > (also mount -a). > > > I think there are two meanings of the word legacy here. > > #1, /etc/fstab on linux is not legacy, and I don't think anyone > here (except possibly for WilliamH as I can't actually tell from > his statements) has been calling it 'legacy' in this context. > >> No, it was alonbl who called it legasy. If you look at how the >> script operates, it would not work without fstab. > >> I simply asked, in response to alonbl, if it really was legasy. > > >> William > Perfect, thank you for the clarification. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlW6UnMACgkQAJxUfCtlWe375gD+LwlTZaMlb3OhyAcisLUsR5+F kf7e47DVX4WHTIAJM9kBAOFGWWge1TvF7oTJ6jpCDSjZ3UKvZSz/VMX4B69d/7tP =qZD4 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
On Thu, Jul 30, 2015 at 12:15:38PM -0400, Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 30/07/15 01:55 AM, Duncan wrote: > > Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as > > excerpted: > > > >> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev > >> wrote: > >> > >>> On 29 July 2015 at 23:20, William Hubbs > >>> wrote: > > so that there is a better idea out there of what I'm talking > about, the OpenRC github repository now has a mount-service > branch. > >>> > >>> But I still trying to figure out why do we need to keep fstab > >>> around. It is pure legacy. > >>> > >>> > >> On what planet is fstab pure legacy? Many utilities use it and > >> expect it to exist. For example the ability to do "mount /foo" > >> requires a properly configured fstab file (also mount -a). > >> > > I think there are two meanings of the word legacy here. > > #1, /etc/fstab on linux is not legacy, and I don't think anyone here > (except possibly for WilliamH as I can't actually tell from his > statements) has been calling it 'legacy' in this context. No, it was alonbl who called it legasy. If you look at how the script operates, it would not work without fstab. I simply asked, in response to alonbl, if it really was legasy. William > > #2, if openrc implements new system mounting which doesn't touch fstab > at all, then by definition /etc/fstab and init scripts that leverage > commands that use it exclusively (old localmount and netmount) are > legacy -- you have the legacy method, and you have the new method. > This is still in the openrc context though, and not in the overall > context of linux. Alon Bar-Lev's comments are definitely using legacy > in this context IMO, and he's right there technically would not be a > need for /etc/fstab on his system with openrc mounting things the new > way that has been suggested, so long as he doesn't intend to use any > tools or commands that expect /etc/fstab in userspace. > > Back to practical matters: > > SO, because /etc/fstab is not legacy (see #1), the new mount system in > openrc needs to be aware of and honour /etc/fstab contents. I've no > idea how to do this, to be honest, as it seems like a clusterfsck to > deal with properly. > > Technically we could require users using openrc from now on to make > symlinks for every mountpoint they want to have mounted at boottime, > but that's IMO an unacceptable amount of work for something that's > never been needed (and IMO never should be -needed-) on linux. As > such, IMO, /etc/fstab should not be turned into a legacy (see #2) > configuration file by openrc. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iF4EAREIAAYFAlW6TakACgkQAJxUfCtlWe2CNQEAmowci81PZYfRr2BJMLCusXEI > MiewLIGDmQqhUc1qnEcA/RrvacCqoBTYIzUzbYuxaUgD/4sdaGPZ70WZYupvIsIO > =Gr62 > -END PGP SIGNATURE- > signature.asc Description: Digital signature
Re: [gentoo-dev] Re: rfc: openrc mount service prototype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/07/15 01:55 AM, Duncan wrote: > Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as > excerpted: > >> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev >> wrote: >> >>> On 29 July 2015 at 23:20, William Hubbs >>> wrote: so that there is a better idea out there of what I'm talking about, the OpenRC github repository now has a mount-service branch. >>> >>> But I still trying to figure out why do we need to keep fstab >>> around. It is pure legacy. >>> >>> >> On what planet is fstab pure legacy? Many utilities use it and >> expect it to exist. For example the ability to do "mount /foo" >> requires a properly configured fstab file (also mount -a). >> I think there are two meanings of the word legacy here. #1, /etc/fstab on linux is not legacy, and I don't think anyone here (except possibly for WilliamH as I can't actually tell from his statements) has been calling it 'legacy' in this context. #2, if openrc implements new system mounting which doesn't touch fstab at all, then by definition /etc/fstab and init scripts that leverage commands that use it exclusively (old localmount and netmount) are legacy -- you have the legacy method, and you have the new method. This is still in the openrc context though, and not in the overall context of linux. Alon Bar-Lev's comments are definitely using legacy in this context IMO, and he's right there technically would not be a need for /etc/fstab on his system with openrc mounting things the new way that has been suggested, so long as he doesn't intend to use any tools or commands that expect /etc/fstab in userspace. Back to practical matters: SO, because /etc/fstab is not legacy (see #1), the new mount system in openrc needs to be aware of and honour /etc/fstab contents. I've no idea how to do this, to be honest, as it seems like a clusterfsck to deal with properly. Technically we could require users using openrc from now on to make symlinks for every mountpoint they want to have mounted at boottime, but that's IMO an unacceptable amount of work for something that's never been needed (and IMO never should be -needed-) on linux. As such, IMO, /etc/fstab should not be turned into a legacy (see #2) configuration file by openrc. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlW6TakACgkQAJxUfCtlWe2CNQEAmowci81PZYfRr2BJMLCusXEI MiewLIGDmQqhUc1qnEcA/RrvacCqoBTYIzUzbYuxaUgD/4sdaGPZ70WZYupvIsIO =Gr62 -END PGP SIGNATURE-
[gentoo-dev] vcs-snapshot.eclass: add a way to specify the extraction path
All,
I'm finding in working on Go ebuilds, that we are propegating a
src_unpack function that is very similar to the one in vcs-snapshot.
This patch adds an EXTRACT_PATH variable to the vcs-snapshot eclass
which, if set, puts the extracted archives in the specified directory under
${S}.
If it is not set, nothing should happen.
This could be used by other types of ebuilds later, but for now it would
be used by Go ebuilds.
Thoughts?
William
Index: vcs-snapshot.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/vcs-snapshot.eclass,v
retrieving revision 1.7
diff -u -B -r1.7 vcs-snapshot.eclass
--- vcs-snapshot.eclass 25 Jul 2013 07:51:16 - 1.7
+++ vcs-snapshot.eclass 30 Jul 2015 15:44:55 -
@@ -40,6 +40,13 @@
*) die "vcs-snapshot.eclass API in EAPI ${EAPI} not yet established."
esac
+# @ECLASS-VARIABLE: EXTRACT_PATH
+# @DESCRIPTION:
+# This is a special purpose variable, mainly used by Go ebuilds, which
+# creates a sub directory under ${S} and stores the extracted archive
+# there. By default, this is empty, and please do not set it in your
+# ebuild unless you know exactly what you are doing.
+
EXPORT_FUNCTIONS src_unpack
# @FUNCTION: vcs-snapshot_src_unpack
@@ -57,13 +64,19 @@
do
case "${f}" in
*.tar|*.tar.gz|*.tar.bz2|*.tar.xz)
-local destdir=${WORKDIR}/${f%.tar*}
+[[ -n $EXTRACT_PATH ]] &&
+ local destdir=${WORKDIR}/${P}/${EXTRACT_PATH} ||
+ local destdir=${WORKDIR}/${f%.tar*}
debug-print "${FUNCNAME}: unpacking ${f} to ${destdir}"
# XXX: check whether the directory structure inside is
# fine? i.e. if the tarball has actually a parent dir.
-mkdir "${destdir}" || die
+if [[ -n ${EXTRACT_PATH} ]]; then
+ mkdir -p "${destdir}" || die
+else
+ mkdir "${destdir}" || die
+fi
tar -C "${destdir}" -x --strip-components 1 \
-f "${DISTDIR}/${f}" || die
;;
signature.asc
Description: Digital signature
Re: [gentoo-dev] rfc: openrc mount service prototype
Patrick McLean: > > On what planet is fstab pure legacy? +1
[gentoo-dev] Last rites: dev-java/cocoon
# James Le Cuirot (30 Jul 2015) # Holding back the removal of Java 6 and upstream is on life # support. Removal in 30 days. See bug #423761. dev-java/cocoon -- James Le Cuirot (chewi) Gentoo Linux Developer
