[gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Yuxuan Shui]

Hi,

I would like to implement cp --reflink support for ZFSOnLinux as my GSoC
project.

cp --reflink is used to create a COW copy of a file, so the file will not
take any disk space if it's not modified. This feature is very useful for
cases like storing a lot of almost identical virtual machine images. Also
this is a frequently requested feature for ZoL. [1][2][3]

Currently only btrfs support this feature, so my goal it to bring it to ZoL
as well.

I think the only way to do it (without changing too many parts of ZoL) is
to use the deduplication feature of zfs. A COW copy could be done by create
a new entry in ddt for the old file, and create a new file which points to
the ddt entry.

Please let me know if this proposal makes sense, and if that's the right
way to do it.

Thanks.

[1]:
https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w
[2]: https://github.com/zfsonlinux/zfs/issues/405
[3]: https://github.com/zfsonlinux/zfs/issues/1063
-- 

Regards
Yuxuan Shui

Re: [gentoo-dev] Python project is looking for a new PyPy maintainer/hacker

[Michał Górny]

Dnia 2014-01-07, o godz. 10:56:16
Alice Ferrazzi  napisał(a):

> I'm interested in helping out,
> I usually use PyPy and im good at python coding.
> I'm not sure about PyPy code but i will check as fast as i can.

Ping. I'm sorry for not replying earlier but I think I expected you'd
write again after checking the code :). Are you still interested?

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Alex Xu]

On 12/03/14 03:15 AM, Yuxuan Shui wrote:
> Hi,
> 
> I would like to implement cp --reflink support for ZFSOnLinux as my GSoC
> project.
> 
> cp --reflink is used to create a COW copy of a file, so the file will not
> take any disk space if it's not modified. This feature is very useful for
> cases like storing a lot of almost identical virtual machine images. Also
> this is a frequently requested feature for ZoL. [1][2][3]
> 
> Currently only btrfs support this feature, so my goal it to bring it to ZoL
> as well.
> 
> I think the only way to do it (without changing too many parts of ZoL) is
> to use the deduplication feature of zfs. A COW copy could be done by create
> a new entry in ddt for the old file, and create a new file which points to
> the ddt entry.
> 
> Please let me know if this proposal makes sense, and if that's the right
> way to do it.
> 
> Thanks.
> 
> [1]:
> https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w
> [2]: https://github.com/zfsonlinux/zfs/issues/405
> [3]: https://github.com/zfsonlinux/zfs/issues/1063
> 

While I can't comment too much on the technical aspects, they seem to be
relatively sound.

However, there are some issues with the, er... other aspects, for lack
of better terminology.

1. This is possibly out of scope as a Gentoo project, since ZOL is not
really part of Gentoo. If it's not, then you're out of luck, because ZOL
is not an accepted organization.

2. This is likely too small to be a GSoC project. Perhaps see [0] for a
list of example ideas, if only so you can get a grasp on the size of a
good project.

It does sound like a good idea though, and even if you can't do it as
part of GSoC, you should pursue it anyways.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gentoo-functions is in the tree

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/03/14 09:10 PM, William Hubbs wrote:
> On Tue, Mar 11, 2014 at 10:10:42AM -0400, Ian Stakenvicius wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> On 10/03/14 07:30 PM, William Hubbs wrote:
>>> All,
>>> 
>>> for bug 373219 [1], we are working on providing a functions.sh
>>> that does not rely on OpenRc so that people who are not using
>>> OpenRc can completely remove it from their systems.
>>> 
>>> I can now report that gentoo-functions has been added to the
>>> tree. Also, I have opened a tracker [2] that explains how to
>>> change packages that source /etc/init.d/functions.sh. They
>>> should first check for the existence of
>>> /lib/gentoo/functions.sh and source that. If it doesn't exist,
>>> they should source /etc/init.d/functions.sh. Also, do not add
>>> hard dependencies to your packages on gentoo-functions. The
>>> goal is to add gentoo-functions to @system once it is stable.
>>> 
>>> The quickest way to find things that will need this fix is to
>>> rm /etc/init.d/functions.sh and file bugs against things that
>>> break and make them block the tracker.
>>> 
>> 
>> - From what I remember about conversations on this in the past,
>> and hopefully vapier can confirm, the de-facto location for this
>> script is supposed to be /etc/init.d/functions.sh.  Was there a
>> general consensus on the approval of that location change?  I
>> still think, at worst, we should ensure the gentoo-functions
>> script installs a symlink here (possibly taking over the one
>> installed by openrc, if openrc still installs one)
> 
> This was discussed at length on the bug. After multiple people
> presented arguments supporting changing this location, vapier was
> given ample time to weigh in with reasons that we shouldn't change
> it. He did not, so it has been changed [1].
> 

yeah.. I scanned that bug, saw his arguments, but didn't see anything
afterwards that seemed to address his arguments (nor anything that
specifically addressed the removal of /etc/init.d/functions.sh as the
de-facto location).

Don't get me wrong, i think it is very pertinent to install the actual
"lib" elsewhere, but since this is still the de-facto location we
should have a symlink.


> No, I don't think gentoo-functions should take over the symbolic
> link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
> My plan there is to work that into a script that prints a warning
> message. It will stay that way until openrc-1.0. OpenRc upstream
> uses semantic versioning [2]. This means that as long as we are at
> 0.x we have to keep things backward compatible.
> 

...why not?  As you've said yourself, nothing related to openrc uses
/etc/init.d/functions.sh; if everything else in the tree is going to
use the new gentoo-functions "lib", why wouldn't custom end-user
scripts too?

(again, scanned the bug, didn't see anything relevant to this)

>> Also, just to confirm, this new path is compatible with the
>> einfo package used as part of Prefix, yes?  Or other arrangements
>> have been made (ie, the einfo package will be dropped from
>> baselayout-prefix)?
> 
> No one has said anything to me about prefix so I don't know what
> they want to do. To be honest I would prefer that they drop einfo.
> unless there is a good reason for them not to.

This is something that should probably be managed, then, before the
migration to gentoo-functions is completed -- anyone here from th
prefix team, that wants to weigh in?  Will gentoo-functions work in
prefix (well enough to replace einfo)?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMgXdIACgkQ2ugaI38ACPCseAD/VLbvGkzN53hx8Z0C9xOHlJxe
VOZu39w+HQhVa5V6vGMA/A+zmmnKjMV1pqJSgCJhgClBu7Ms9QeauZKcvjeKddqx
=Ozpu
-END PGP SIGNATURE-

[gentoo-dev] Re: GSoC proposal: cp --reflink support for zfs.

[Richard Yao]

A key feature of reflinks is that they operate on any data in a mountpoint, but 
what you described only applies to data with a deduplication table entry. In 
such cases, it do not see what it accomplishes over simply using data 
deduplication. In specific, there is no efficiency advantage. It is not clear 
to me that trying to cut corners to obtain one is possible without incurring 
consistency issues with the deduplication table falling out of sync. In the 
case that there is no deduplication table entry, you would need to rewrite the 
file. reflinks are intended to be as done as quickly as hard links, so this 
would seem to negate the benefit.

Matthew Ahrens and I have discussed reflinks in the past and we both agree that 
they would be non-trivial to implement. That does not mean it cannot be done, 
but I do not think this particular approach would succeed. However, I encourage 
you to keep thinking about such things. If you think of a way of doing this 
that seems workable, it would likely be something that could be made into a 
GSoC project.

With that said, if you want to do a ZoL-related project for Gentoo, I have some 
other things that I could suggest that I believe are workable. Such ideas are 
things that I was asked to prepare on extremely short notice and I have not yet 
had time to publish them. Let me know if you would be interested.

On Mar 12, 2014, at 3:15 AM, Yuxuan Shui  wrote:

> Hi,
> 
> I would like to implement cp --reflink support for ZFSOnLinux as my GSoC 
> project.
> 
> cp --reflink is used to create a COW copy of a file, so the file will not 
> take any disk space if it's not modified. This feature is very useful for 
> cases like storing a lot of almost identical virtual machine images. Also 
> this is a frequently requested feature for ZoL. [1][2][3]
> 
> Currently only btrfs support this feature, so my goal it to bring it to ZoL 
> as well.
> 
> I think the only way to do it (without changing too many parts of ZoL) is to 
> use the deduplication feature of zfs. A COW copy could be done by create a 
> new entry in ddt for the old file, and create a new file which points to the 
> ddt entry.
> 
> Please let me know if this proposal makes sense, and if that's the right way 
> to do it.
> 
> Thanks.
> 
> [1]: 
> https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w
> [2]: https://github.com/zfsonlinux/zfs/issues/405
> [3]: https://github.com/zfsonlinux/zfs/issues/1063
> -- 
> 
> Regards
> Yuxuan Shui

Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

[Peter Stuge]

Gilles Dartiguelongue wrote:
> Making udev dependency always on is a deliberate choice here

I thought Gentoo was about users having choice? Sad face.


> we simply don't want users to get confused

That's not helpful, when the premise is to deliver choice.


I hope someone does apply the patch.


//Peter


pgpwCf0CNVRjg.pgp
Description: PGP signature

Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Richard Yao]

On 03/12/2014 08:45 AM, Alex Xu wrote:
> On 12/03/14 03:15 AM, Yuxuan Shui wrote:
>> Hi,
>>
>> I would like to implement cp --reflink support for ZFSOnLinux as my GSoC
>> project.
>>
>> cp --reflink is used to create a COW copy of a file, so the file will not
>> take any disk space if it's not modified. This feature is very useful for
>> cases like storing a lot of almost identical virtual machine images. Also
>> this is a frequently requested feature for ZoL. [1][2][3]
>>
>> Currently only btrfs support this feature, so my goal it to bring it to ZoL
>> as well.
>>
>> I think the only way to do it (without changing too many parts of ZoL) is
>> to use the deduplication feature of zfs. A COW copy could be done by create
>> a new entry in ddt for the old file, and create a new file which points to
>> the ddt entry.
>>
>> Please let me know if this proposal makes sense, and if that's the right
>> way to do it.
>>
>> Thanks.
>>
>> [1]:
>> https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w
>> [2]: https://github.com/zfsonlinux/zfs/issues/405
>> [3]: https://github.com/zfsonlinux/zfs/issues/1063
>>
> 
> While I can't comment too much on the technical aspects, they seem to be
> relatively sound.
> 
> However, there are some issues with the, er... other aspects, for lack
> of better terminology.
> 
> 1. This is possibly out of scope as a Gentoo project, since ZOL is not
> really part of Gentoo. If it's not, then you're out of luck, because ZOL
> is not an accepted organization.

Things that provide us with improvements over what we have are
definitely worth consideration as GSoC projects. However, what is
accepted ultimately depends on not only feedback from a potential
mentor, but also a vote of Gentoo developers.

> 2. This is likely too small to be a GSoC project. Perhaps see [0] for a
> list of example ideas, if only so you can get a grasp on the size of a
> good project.
> 
> It does sound like a good idea though, and even if you can't do it as
> part of GSoC, you should pursue it anyways.

Leaning on my understanding of ZFS internals, I can say that this is
large enough. However, I do not think it will accomplish the desired
result if implemented in the manner suggested.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

[Alexandre Rostovtsev]

On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote:
> Gilles Dartiguelongue wrote:
> > Making udev dependency always on is a deliberate choice here
> 
> I thought Gentoo was about users having choice? Sad face.

Gentoo is usually about the maintainer's choice ;)

So in the end it's up to Pacho:
https://bugs.gentoo.org/show_bug.cgi?id=504324


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] crossdev and multilib interference

[hasufell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

We have a problem where the crossdev pkg-config wrapper scripts
interfere with multilib.

crossdev for example sets in their pkg-config wrappers:

PKG_CONFIG_LIBDIR="${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig"

Now, SYSROOT is chosen from multiple conditions. When emerging a
package, that happens to be "/" and thus results in:
  "//usr/lib/pkgconfig://usr/share/pkgconfig"

Build systems like autotools will pick the crossdev provided
"i686-pc-linux-gnu-pkg-config" for the 32bit ABI which will in turn
override the eclass-exported PKG_CONFIG_LIBDIR and now effectively
find the pkg-config files in /usr/lib64/...

This is not a problem most of the time if the package just wants to
get the libs to link against.

However, every package that tries to access variables that are
different between /usr/lib32/pkgconfig/foo.pc and
/usr/lib64/pkgconfig/foo.pc like "libdir" will fail or produce
unexpected results.

That already happens for
x11-libs/libva-vdpau-driver
x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=500338)

and there are probably more.

A simple workaround is:
PKG_CONFIG="pkg-config" emerge foo

But I think that is not appropriate to set in the eclass. How can we
solve this? Don't bikeshed.
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJTIIE5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzMDlCNDQ4NjEyNDI4NjA5REVEMDI3MzIy
MjBDRDFDNUJERUVEMDIwAAoJECIM0cW97tAgLvMQALJT5uZFBTL5mHNBjezudMHo
ceHY3TzLfeIkWHedCLU9TAapfLjl677W0jbg25zkLayPtUR3voEAIm6xFZtF2CAS
VsBpArieXQWqtxSrT9hHC1dJeAWQvQs1kyKXBb5ido8sEBb7WpHFlEqwmUY5bn33
TZjGjcQ68EojbcFQl0vmJRx1/bgXxOr9Ir4Y1bFX92S9ENhERnisu3zZrcvC+PyH
XqXg+wFoJfxu1fSL4/llRDfyr0UJWlWdMeCpvwgkhCpn66CBwc50BwokMP4f4x3G
YDbi+1Ep4GIBVHLd5MlfZOkeqhzPQRD10lbnOHmW7Wuh6Mu87UI7G9xHWZcNyEkS
U9Ny0ejyqnx0j5TMgMP/IcpBR1PaRcceTLFYhwJrYucgcB6/YZ1sP81Yce7f2Riy
M6OZontsv8GVbPA4tsgsV4wob6XUzn6d47p4jwbq67u3GUX6QU7fNB0yJ2ga56qV
xvIaEgdOFsAZHOyix6zfTa2AqpE2LQiVfwEF2pI4J4bTCfy7DvfWhuvA5IwWyyFA
jPiGr5xEns85v2q+dagUo/iup9gzbgGQs+dH6w3wXTkip72lnbxHwiz8Pa2eIXVl
+Tvo9vcdVSzw68tF30sS005+HNorCkj/pqdC7FND/KCyC7r3aESmagibqKdUhHPc
9sN1RjgyzXYst5mvQ1Hg
=J4Qp
-END PGP SIGNATURE-

Re: [gentoo-dev] crossdev and multilib interference

[Alexandre Rostovtsev]

On Wed, 2014-03-12 at 15:46 +, hasufell wrote:
> We have a problem where the crossdev pkg-config wrapper scripts
> interfere with multilib.
> 
> crossdev for example sets in their pkg-config wrappers:
> 
> PKG_CONFIG_LIBDIR="${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig"
> 
> Now, SYSROOT is chosen from multiple conditions. When emerging a
> package, that happens to be "/" and thus results in:
>   "//usr/lib/pkgconfig://usr/share/pkgconfig"
> 
> Build systems like autotools will pick the crossdev provided
> "i686-pc-linux-gnu-pkg-config" for the 32bit ABI which will in turn
> override the eclass-exported PKG_CONFIG_LIBDIR and now effectively
> find the pkg-config files in /usr/lib64/...
> 
> This is not a problem most of the time if the package just wants to
> get the libs to link against.
> 
> However, every package that tries to access variables that are
> different between /usr/lib32/pkgconfig/foo.pc and
> /usr/lib64/pkgconfig/foo.pc like "libdir" will fail or produce
> unexpected results.
> 
> That already happens for
> x11-libs/libva-vdpau-driver
> x11-libs/libva (https://bugs.gentoo.org/show_bug.cgi?id=500338)
> 
> and there are probably more.
> 
> A simple workaround is:
> PKG_CONFIG="pkg-config" emerge foo
> 
> But I think that is not appropriate to set in the eclass. How can we
> solve this? Don't bikeshed.

Two possibilities:
1. Don't allow crossdev to handle targets which are natively handled by
multilib profiles. For example, is there any legitimate reason for
wanting crossdev's i686 wrappers when on a multilib amd64 profile?
2. Have crossdev install its wrappers in a prefix, for example
in /usr/libexec/crossdev, which gets added to PATH by cross-emerge.


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] gentoo-functions is in the tree

[William Hubbs]

On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
> yeah.. I scanned that bug, saw his arguments, but didn't see anything
> afterwards that seemed to address his arguments (nor anything that
> specifically addressed the removal of /etc/init.d/functions.sh as the
> de-facto location).

https://bugs.gentoo.org/show_bug.cgi?id=373219#C74

This is the first point when I proposed moving the file with a good
argument and asked vapier to weigh in.
 
 Below are several points in the discussion where it was made clear that
 we were moving the file, and also vapier participated in reviewing
 alternate implementations. He suggested making this part of baselayout
 instead of introducing a new package. I asked him to connect with me so
 we could talk about why he felt that was a good place for it (since I
 didn't because it may need more maintenance than baselayout does). That
 connect never happened for whatever reason.

 https://bugs.gentoo.org/show_bug.cgi?id=373219#C93
 https://bugs.gentoo.org/show_bug.cgi?id=373219#C95
 https://bugs.gentoo.org/show_bug.cgi?id=373219#C96
 https://bugs.gentoo.org/show_bug.cgi?id=373219#C116
 https://bugs.gentoo.org/show_bug.cgi?id=373219#C119
 https://bugs.gentoo.org/show_bug.cgi?id=373219#C120
 https://bugs.gentoo.org/show_bug.cgi?id=373219#C124

> > No, I don't think gentoo-functions should take over the symbolic
> > link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
> > My plan there is to work that into a script that prints a warning
> > message. It will stay that way until openrc-1.0. OpenRc upstream
> > uses semantic versioning [2]. This means that as long as we are at
> > 0.x we have to keep things backward compatible.
> > 
> 
> ...why not?  As you've said yourself, nothing related to openrc uses
> /etc/init.d/functions.sh; if everything else in the tree is going to
> use the new gentoo-functions "lib", why wouldn't custom end-user
> scripts too?
> 
> (again, scanned the bug, didn't see anything relevant to this)

The relevance is that /etc/init.d/functions.sh is currently part of
OpenRc's public API, and semantic versioning has a very specific
description of how to deprecate functionality.

If Gentoo needs the symlink after it is removed from OpenRc, I think
that is the time we can talk about putting it in gentoo-functions.

> >> Also, just to confirm, this new path is compatible with the
> >> einfo package used as part of Prefix, yes?  Or other arrangements
> >> have been made (ie, the einfo package will be dropped from
> >> baselayout-prefix)?
> > 
> > No one has said anything to me about prefix so I don't know what
> > they want to do. To be honest I would prefer that they drop einfo.
> > unless there is a good reason for them not to.
> 
> This is something that should probably be managed, then, before the
> migration to gentoo-functions is completed -- anyone here from th
> prefix team, that wants to weigh in?  Will gentoo-functions work in
> prefix (well enough to replace einfo)?

https://bugs.gentoo.org/show_bug.cgi?id=504284

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] gentoo-functions is in the tree

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/03/14 07:30 PM, William Hubbs wrote:
> The quickest way to find things that will need this fix is to rm 
> /etc/init.d/functions.sh and file bugs against things that break
> and make them block the tracker.

..is there a tracker bug currently?  I did a search but I didn't see
anything in particular.  It doesn't seem right to use the main bug
373219 ...



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMgkxUACgkQ2ugaI38ACPArRwD9GpFiGgI9K6YwYgWPzaUD9trX
7WFyEXPYvLWZqB9YHgkBAIMnKJVki5M++EuU0AgSbcef0074+eeUixG/v/xcokRK
=Hfde
-END PGP SIGNATURE-

Re: [gentoo-dev] gentoo-functions is in the tree

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/03/14 12:52 PM, William Hubbs wrote:
> 
> The relevance is that /etc/init.d/functions.sh is currently part
> of OpenRc's public API, and semantic versioning has a very
> specific description of how to deprecate functionality.
> 
> If Gentoo needs the symlink after it is removed from OpenRc, I
> think that is the time we can talk about putting it in
> gentoo-functions.


Perfect.  So long as that path remains intact from the perspective of
gentoo's end-users.

Thanks!

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMgkzYACgkQ2ugaI38ACPBEQgD/W46QG4tmqFLGQtwCeBgKkwZp
QwvsgrGr4UK9SpiM/6ABAL+OStinQ3PYskf+CdmoCXl6lIsCcMYfifmJ5La56N4s
=kXCH
-END PGP SIGNATURE-

Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Yuxuan Shui]

Hi,

On Wed, Mar 12, 2014 at 9:30 PM, Richard Yao  wrote:
>
> On 03/12/2014 08:45 AM, Alex Xu wrote:
> > On 12/03/14 03:15 AM, Yuxuan Shui wrote:
> >> Hi,
> >>
> >> I would like to implement cp --reflink support for ZFSOnLinux as my GSoC
> >> project.
> >>
> >> cp --reflink is used to create a COW copy of a file, so the file will not
> >> take any disk space if it's not modified. This feature is very useful for
> >> cases like storing a lot of almost identical virtual machine images. Also
> >> this is a frequently requested feature for ZoL. [1][2][3]
> >>
> >> Currently only btrfs support this feature, so my goal it to bring it to ZoL
> >> as well.
> >>
> >> I think the only way to do it (without changing too many parts of ZoL) is
> >> to use the deduplication feature of zfs. A COW copy could be done by create
> >> a new entry in ddt for the old file, and create a new file which points to
> >> the ddt entry.
> >>
> >> Please let me know if this proposal makes sense, and if that's the right
> >> way to do it.
> >>
> >> Thanks.
> >>
> >> [1]:
> >> https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/mvGB7QEpt3w
> >> [2]: https://github.com/zfsonlinux/zfs/issues/405
> >> [3]: https://github.com/zfsonlinux/zfs/issues/1063
> >>
> >
> > While I can't comment too much on the technical aspects, they seem to be
> > relatively sound.
> >
> > However, there are some issues with the, er... other aspects, for lack
> > of better terminology.
> >
> > 1. This is possibly out of scope as a Gentoo project, since ZOL is not
> > really part of Gentoo. If it's not, then you're out of luck, because ZOL
> > is not an accepted organization.
>
> Things that provide us with improvements over what we have are
> definitely worth consideration as GSoC projects. However, what is
> accepted ultimately depends on not only feedback from a potential
> mentor, but also a vote of Gentoo developers.

Maybe I could propose this project to illumos? Since they seems to
accept proposal for OpenZFS.

>
> > 2. This is likely too small to be a GSoC project. Perhaps see [0] for a
> > list of example ideas, if only so you can get a grasp on the size of a
> > good project.
> >
> > It does sound like a good idea though, and even if you can't do it as
> > part of GSoC, you should pursue it anyways.
>
> Leaning on my understanding of ZFS internals, I can say that this is
> large enough. However, I do not think it will accomplish the desired
> result if implemented in the manner suggested.

Could you elaborate why this won't work? Thanks.

>

-- 

Regards
Yuxuan Shui

Re: [gentoo-dev] gentoo-functions is in the tree

[Rich Freeman]

On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs  wrote:
> On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
>> ...why not?  As you've said yourself, nothing related to openrc uses
>> /etc/init.d/functions.sh; if everything else in the tree is going to
>> use the new gentoo-functions "lib", why wouldn't custom end-user
>> scripts too?
>>
>> (again, scanned the bug, didn't see anything relevant to this)
>
> The relevance is that /etc/init.d/functions.sh is currently part of
> OpenRc's public API, and semantic versioning has a very specific
> description of how to deprecate functionality.
>
> If Gentoo needs the symlink after it is removed from OpenRc, I think
> that is the time we can talk about putting it in gentoo-functions.
>

If the goal is to be able to remove openrc from systems, how does it
help that we might fix any breakage after openrc no longer provides
it?

If the goal is to be able to remove openrc from systems, then
something else needs to provide the symlink.  I guess in the meantime
users could just remove openrc and just manually install the symlink,
but that isn't really a clean solution.

Otherwise openrc can't be removed until anything that sources this is
fixed.  If it all does get fixed, then the symlink isn't even needed
(though I suppose openrc can still provide it for any other distros
that use it).

Rich

Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Rich Freeman]

On Wed, Mar 12, 2014 at 9:30 AM, Richard Yao  wrote:
> Things that provide us with improvements over what we have are
> definitely worth consideration as GSoC projects. However, what is
> accepted ultimately depends on not only feedback from a potential
> mentor, but also a vote of Gentoo developers.

Honestly, this seems like a less-than-ideal fit for Gentoo.  We don't
really use ZFS at all, other than as yet another package in our tree.
Any of the Mozilla/ GSoC ideas would make as much sense to deliver as
part of the Gentoo GSoC.

Now, if this were about integrating auto-snapshots into the package
manager, (like can be done with snapper), etc, then I could see more
relevance (though it probably wouldn't rise to a full project).  I
could also see some kind of project to integrate advanced filesystem
features into core elements of our distro across many filesystems
(though I don't really see the relevance for reflinks in particular,
and they only apply to COW filesystems anyway).

This just seems like a ZFS project, and not like a Gentoo project.
I'd say the same if this were about adding a mute button to tabs in
Chromium, or fixing the offline btrfsck, or whatever.  All of those
things would be useful to Gentoo, but only insofar as they'd be useful
to anybody.

Rich

Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Paul Tagliamonte]

On Wed, Mar 12, 2014 at 01:19:08PM -0400, Rich Freeman wrote:
> This just seems like a ZFS project, and not like a Gentoo project.
> I'd say the same if this were about adding a mute button to tabs in
> Chromium, or fixing the offline btrfsck, or whatever.  All of those
> things would be useful to Gentoo, but only insofar as they'd be useful
> to anybody.

Agreed. Your dear friends in Debian would enjoy such changes as well, for
those using zfs with kfreebsd or a home build of the zol package. Perhaps
this would be a fit for upstream?

> Rich

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: [gentoo-dev] gentoo-functions is in the tree

[William Hubbs]

On Wed, Mar 12, 2014 at 01:08:43PM -0400, Rich Freeman wrote:
> On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs  wrote:
> > On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
> >> ...why not?  As you've said yourself, nothing related to openrc uses
> >> /etc/init.d/functions.sh; if everything else in the tree is going to
> >> use the new gentoo-functions "lib", why wouldn't custom end-user
> >> scripts too?
> >>
> >> (again, scanned the bug, didn't see anything relevant to this)
> >
> > The relevance is that /etc/init.d/functions.sh is currently part of
> > OpenRc's public API, and semantic versioning has a very specific
> > description of how to deprecate functionality.
> >
> > If Gentoo needs the symlink after it is removed from OpenRc, I think
> > that is the time we can talk about putting it in gentoo-functions.
> >
> 
> If the goal is to be able to remove openrc from systems, how does it
> help that we might fix any breakage after openrc no longer provides
> it?

I don't follow this question.

> If the goal is to be able to remove openrc from systems, then
> something else needs to provide the symlink.  I guess in the meantime
> users could just remove openrc and just manually install the symlink,
> but that isn't really a clean solution.
> 
> Otherwise openrc can't be removed until anything that sources this is
> fixed.  If it all does get fixed, then the symlink isn't even needed
> (though I suppose openrc can still provide it for any other distros
> that use it).

Here is what I'm going to do inside openrc:

/etc/init.d/functions.sh, which is a symlink now, will become an actual
script that does the following:

source "@LIBEXECDIR@"/sh/functions.sh
ewarn "$0: sourcing /etc/init.d/functions.sh is deprecated."
ewarn "This file will be removed in a future version of OpenRc, so please"
ewarn "source \"@LIBEXECDIR@\"/sh/functions.sh if you need this functionality."

Where @LIBEXECDIR@ is replaced at build time with OpenRc's libexecdir
setting.

From the gentoo side, when bugs are filed, the maintainers will have to
make a decision about whether to source /lib/gentoo/functions.sh or
@LIBEXECDIR@/sh/functions.sh based on whether their package really needs
OpenRc specific functionality or not.

Gentoo end users who are sourcing /etc/init.d/functions.sh will have to
make the same decision.

Non-gentoo end users will know what they have to do -- fix
their scripts to  source @LIBEXECDIR@/sh/functions.sh.

So, I am having trouble seeing why the symlink will be needed at all
after OpenRc removes this script in OpenRc 1.0.

William


signature.asc
Description: Digital signature

[gentoo-dev] Re: GSoC '14 - Improved Cloud Support - Draft proposal

[Proneet Verma]

Hi,

On Tue, Mar 11, 2014 at 11:24 PM, Proneet Verma  wrote:

> Hi,
>
> I am interested in working on the project "Improved Cloud 
> Support"
> for GSoC '14; for which I have drafted out my proposal for your kind
> perusal here .
>

Some key points of the proposal:-

1) Currently, catalyst doesn't have support for building AMIs for cloud
services, I would like to add this feature to the Catalyst project so that
the releng team can provide Gentoo on AWS using the stages and portage
snapshot which can be built with the gentoo-catalyst tool. Here, I would be
using ec2-{ api, ami }-tools to script actions on EC2 and basically do a
typical handbook install.

2) Docker is an open source tool to easily create lightweight and self
sufficient containers. I would like to enhance the puppet-docker support to
spawn containers with the help of Puppet which is an automation tool for
system administration. Currently,
this has
support for Ubuntu and RedHat distributions, so I would like to add Gentoo
support into it.

3) Jenkins CI is a very popular monitoring tool, and as it isn't there in
the portage tree I would like to write ebuilds for it and become a proxy
maintainer for future support.

4) I am also looking forward to add binary package support for commonly
used packages by cloud users (like nginx, mysql, mongodb etc) as they don't
have much CPU to do on system compiling. Also, this can be improvised as,
writing Puppet class which can help in sharing packages (portage_binhost)
built once across all your systems (compiling once and using it
everywhere). Need to put in more thoughts to this part!


> Please provide your feedback.
>
> Thanking you in anticipation.
>
> Regards,
> Proneet Verma
> (irc: proneet @freenode)
>

Re: [gentoo-dev] crossdev and multilib interference

[Alexis Ballier]

On Wed, 12 Mar 2014 12:06:32 -0400
Alexandre Rostovtsev  wrote:

> Two possibilities:
> 1. Don't allow crossdev to handle targets which are natively handled
> by multilib profiles. For example, is there any legitimate reason for
> wanting crossdev's i686 wrappers when on a multilib amd64 profile?

yes, serving as a distcc server for x86 hosts or using 'cross emerge'
to build a x86 root from scratch

> 2. Have crossdev install its wrappers in a prefix, for example
> in /usr/libexec/crossdev, which gets added to PATH by cross-emerge.

lgtm

Re: [gentoo-dev] gentoo-functions is in the tree

[Tom Wijsman]

On Wed, 12 Mar 2014 13:02:13 -0400
Ian Stakenvicius  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 10/03/14 07:30 PM, William Hubbs wrote:
> > The quickest way to find things that will need this fix is to rm 
> > /etc/init.d/functions.sh and file bugs against things that break
> > and make them block the tracker.
> 
> ..is there a tracker bug currently?

https://bugs.gentoo.org/show_bug.cgi?id=504116

Alias: functions.sh

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: [gentoo-dev] gentoo-functions is in the tree

[William Hubbs]

On Wed, Mar 12, 2014 at 01:02:13PM -0400, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 10/03/14 07:30 PM, William Hubbs wrote:
> > The quickest way to find things that will need this fix is to rm 
> > /etc/init.d/functions.sh and file bugs against things that break
> > and make them block the tracker.
> 
> ..is there a tracker bug currently?  I did a search but I didn't see
> anything in particular.  It doesn't seem right to use the main bug
> 373219 ...

http://bugs.gentoo.org/show_bug.cgi?id=504116

I thought I mentioned it earlier in the thread; sorry about that.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] gentoo-functions is in the tree

[William Hubbs]

All,

thinking about this further,

There may not be a need to remove /etc/init.d/functions.sh as long as it
is understood that this is part of OpenRc, not the gentoo base.

In other words, tools that must work when OpenRc is not present should
source /lib/gentoo/functions.sh, NOT /etc/init.d/functions.sh.

What are your thoughts on this approach?

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] gentoo-functions is in the tree

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/03/14 03:59 PM, William Hubbs wrote:
> All,
> 
> thinking about this further,
> 
> There may not be a need to remove /etc/init.d/functions.sh as long
> as it is understood that this is part of OpenRc, not the gentoo
> base.
> 
> In other words, tools that must work when OpenRc is not present
> should source /lib/gentoo/functions.sh, NOT
> /etc/init.d/functions.sh.
> 
> What are your thoughts on this approach?
> 
> William
> 


Well, this will leave the de-facto path intact for the majority of
users, which sounds great to me.

This path -wont- be available for users that don't have openrc
installed, but then, if all of the tools in portage are converted to
use /lib/gentoo/functions.sh this probably won't matter -- i dont
think many custom script writers using a systemd system will care
about output consistency with openrc anyhow.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMgwZoACgkQ2ugaI38ACPDcPgEAhSkoJma2GVfUeKpRoIcvHEQD
tivcbFdpHRF3xTtssUYA/RXQvFCkwyqiALsu1Jm94fGTsjT1aCHxYA96oefY++Fv
=Vu5p
-END PGP SIGNATURE-

Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

[Rich Freeman]

On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev
 wrote:
> On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote:
>> Gilles Dartiguelongue wrote:
>> > Making udev dependency always on is a deliberate choice here
>>
>> I thought Gentoo was about users having choice? Sad face.
>
> Gentoo is usually about the maintainer's choice ;)
>
> So in the end it's up to Pacho:
> https://bugs.gentoo.org/show_bug.cgi?id=504324

Honestly, of all the suggestions in this thread having the use-enable
config setting and just outputting a warning when udev isn't enabled
seems like the best solution.

Sure, it is up to the maintainer, but in general we should try to
support config options like this.  If we only wanted packages that
"just work" with no risk of breakage we'd be running debian.  USE
flags are a big point of what we're about.

Anybody setting USE=-udev system-wide needs to appreciate that stuff
like usb/bluetooth/etc which is runtime auto-configuring is fairly
likely to not work.  The profile defaults already seem reasonable, so
it shouldn't be necessary to force it off for a typical user - base
users will tend to get udev only if they install something like bluez,
which is what 95% of users will want.  For those who want to override
the defaults we should give them the option to shoot themselves in
both feet and the head as well if they are eager.

Users who really want the "Debian-like" experience should just avoid
setting use flags at all and pick a profile.  USE defaults and
profiles really eliminate the "need" to tweak that stuff, and emerge
can auto-set package settings if required for a dependency.

Rich

Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

[Joshua Kinard]

On 03/12/2014 4:21 PM, Rich Freeman wrote:
> On Wed, Mar 12, 2014 at 11:16 AM, Alexandre Rostovtsev
>  wrote:
>> On Wed, 2014-03-12 at 14:24 +0100, Peter Stuge wrote:
>>> Gilles Dartiguelongue wrote:
 Making udev dependency always on is a deliberate choice here
>>>
>>> I thought Gentoo was about users having choice? Sad face.
>>
>> Gentoo is usually about the maintainer's choice ;)
>>
>> So in the end it's up to Pacho:
>> https://bugs.gentoo.org/show_bug.cgi?id=504324
> 
> Honestly, of all the suggestions in this thread having the use-enable
> config setting and just outputting a warning when udev isn't enabled
> seems like the best solution.

Agreed, Alex's patch properly addresses the issue I originally raised.  My
initial thinking was to replace virtual/udev with the more generic
virtual/dev-manager, because I didn't dig deep into understanding why
virtual/udev was actually needed (I don't use bluetooth on a daily basis).


-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Richard Yao]

It is a moot point because I do not think this project idea is feasible.

On Mar 12, 2014, at 1:19 PM, Rich Freeman  wrote:

> On Wed, Mar 12, 2014 at 9:30 AM, Richard Yao  wrote:
>> Things that provide us with improvements over what we have are
>> definitely worth consideration as GSoC projects. However, what is
>> accepted ultimately depends on not only feedback from a potential
>> mentor, but also a vote of Gentoo developers.
> 
> Honestly, this seems like a less-than-ideal fit for Gentoo.  We don't
> really use ZFS at all, other than as yet another package in our tree.
> Any of the Mozilla/ GSoC ideas would make as much sense to deliver as
> part of the Gentoo GSoC.
> 
> Now, if this were about integrating auto-snapshots into the package
> manager, (like can be done with snapper), etc, then I could see more
> relevance (though it probably wouldn't rise to a full project).  I
> could also see some kind of project to integrate advanced filesystem
> features into core elements of our distro across many filesystems
> (though I don't really see the relevance for reflinks in particular,
> and they only apply to COW filesystems anyway).
> 
> This just seems like a ZFS project, and not like a Gentoo project.
> I'd say the same if this were about adding a mute button to tabs in
> Chromium, or fixing the offline btrfsck, or whatever.  All of those
> things would be useful to Gentoo, but only insofar as they'd be useful
> to anybody.
> 
> Rich
> 

Re: [gentoo-dev] GSoC proposal: cp --reflink support for zfs.

[Richard Yao]

I do not think the original project idea is feasible as stated.

On Mar 12, 2014, at 1:22 PM, Paul Tagliamonte  wrote:

> On Wed, Mar 12, 2014 at 01:19:08PM -0400, Rich Freeman wrote:
>> This just seems like a ZFS project, and not like a Gentoo project.
>> I'd say the same if this were about adding a mute button to tabs in
>> Chromium, or fixing the offline btrfsck, or whatever.  All of those
>> things would be useful to Gentoo, but only insofar as they'd be useful
>> to anybody.
> 
> Agreed. Your dear friends in Debian would enjoy such changes as well, for
> those using zfs with kfreebsd or a home build of the zol package. Perhaps
> this would be a fit for upstream?
> 
>> Rich
> 
> Cheers,
>  Paul
> 
> -- 
> .''`.  Paul Tagliamonte   |   Proud Debian Developer
> : :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
> `. `'`  http://people.debian.org/~paultag
> `- http://people.debian.org/~paultag/conduct-statement.txt

Re: [gentoo-dev] gentoo-functions is in the tree

[Patrick Lauer]

On 03/13/2014 12:52 AM, William Hubbs wrote:

>>> No, I don't think gentoo-functions should take over the symbolic
>>> link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
>>> My plan there is to work that into a script that prints a warning
>>> message. It will stay that way until openrc-1.0. OpenRc upstream
>>> uses semantic versioning [2]. This means that as long as we are at
>>> 0.x we have to keep things backward compatible.
>>>
>>
>> ...why not?  As you've said yourself, nothing related to openrc uses
>> /etc/init.d/functions.sh; if everything else in the tree is going to
>> use the new gentoo-functions "lib", why wouldn't custom end-user
>> scripts too?
>>
>> (again, scanned the bug, didn't see anything relevant to this)
> 
> The relevance is that /etc/init.d/functions.sh is currently part of
> OpenRc's public API, and semantic versioning has a very specific
> description of how to deprecate functionality.

Why deprecate it?

I'm getting really irritated with the current trend of randomly renaming
and movearounding things. All it does is confuse people, break existing
setups and make documentation splitbrained (now you need to document two
things, and half the old docs won't be aware of it ...)

So I guess it boils down to "What does the /usr movearounding gain us",
err, what does renaming bits of OpenRC improve?

The best explanations so far I've seen are "it's nicer", "we've already
done it" and "eh mate, why not? is groovy"

> If Gentoo needs the symlink after it is removed from OpenRc, I think
> that is the time we can talk about putting it in gentoo-functions.

Now that is funny, but why move it away just so that users panic and
re-add the wrong flavour of it?

Well, progress I guess: If you change enough things in trivial ways you
can claim innovation and show a great rate of change ("I'm not dead yet!")


grmblgr,

Patrick

Re: [gentoo-dev] gentoo-functions is in the tree

[Patrick McLean]

On Thu, 13 Mar 2014 07:59:55 +0800
Patrick Lauer  wrote:

> On 03/13/2014 12:52 AM, William Hubbs wrote:
> 
> Why deprecate it?
> 
> I'm getting really irritated with the current trend of randomly
> renaming and movearounding things. All it does is confuse people,
> break existing setups and make documentation splitbrained (now you
> need to document two things, and half the old docs won't be aware of
> it ...)
> 
> So I guess it boils down to "What does the /usr movearounding gain
> us", err, what does renaming bits of OpenRC improve?
> 
> The best explanations so far I've seen are "it's nicer", "we've
> already done it" and "eh mate, why not? is groovy"
> 
> > If Gentoo needs the symlink after it is removed from OpenRc, I think
> > that is the time we can talk about putting it in gentoo-functions.
> 
> Now that is funny, but why move it away just so that users panic and
> re-add the wrong flavour of it?
> 
> Well, progress I guess: If you change enough things in trivial ways
> you can claim innovation and show a great rate of change ("I'm not
> dead yet!")
> 

I would say it's because library code such as that really does not
belong in /etc and placing it there in the first place was a mistake.
This is an attempt to correct the mistake without just breaking
everything without warning.

Re: [gentoo-dev] gentoo-functions is in the tree

[Joshua Kinard]

On 03/12/2014 7:59 PM, Patrick Lauer wrote:
> On 03/13/2014 12:52 AM, William Hubbs wrote:
> 
 No, I don't think gentoo-functions should take over the symbolic
 link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
 My plan there is to work that into a script that prints a warning
 message. It will stay that way until openrc-1.0. OpenRc upstream
 uses semantic versioning [2]. This means that as long as we are at
 0.x we have to keep things backward compatible.

>>>
>>> ...why not?  As you've said yourself, nothing related to openrc uses
>>> /etc/init.d/functions.sh; if everything else in the tree is going to
>>> use the new gentoo-functions "lib", why wouldn't custom end-user
>>> scripts too?
>>>
>>> (again, scanned the bug, didn't see anything relevant to this)
>>
>> The relevance is that /etc/init.d/functions.sh is currently part of
>> OpenRc's public API, and semantic versioning has a very specific
>> description of how to deprecate functionality.
> 
> Why deprecate it?
> 
> I'm getting really irritated with the current trend of randomly renaming
> and movearounding things. All it does is confuse people, break existing
> setups and make documentation splitbrained (now you need to document two
> things, and half the old docs won't be aware of it ...)
> 
> So I guess it boils down to "What does the /usr movearounding gain us",
> err, what does renaming bits of OpenRC improve?
> 
> The best explanations so far I've seen are "it's nicer", "we've already
> done it" and "eh mate, why not? is groovy"
> 
>> If Gentoo needs the symlink after it is removed from OpenRc, I think
>> that is the time we can talk about putting it in gentoo-functions.
> 
> Now that is funny, but why move it away just so that users panic and
> re-add the wrong flavour of it?
> 
> Well, progress I guess: If you change enough things in trivial ways you
> can claim innovation and show a great rate of change ("I'm not dead yet!")

Maybe we should write another script for OpenRC that, at each boot,
determines a random location in your filesystem and moves
/etc/init.d/functions.sh there, but moves it back on system shutdown.  It'll
also go through all scripts that source functions.sh and update them to
point at the new, random location, each time.

We'll also need a type of openrc-fsck script that handles cases of unclean
shutdowns that don't move the file back to /etc (or /lib, or both).

Now that's innovation!

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] gentoo-functions is in the tree

[Michał Górny]

Dnia 2014-03-13, o godz. 07:59:55
Patrick Lauer  napisał(a):

> On 03/13/2014 12:52 AM, William Hubbs wrote:
> 
> >>> No, I don't think gentoo-functions should take over the symbolic
> >>> link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
> >>> My plan there is to work that into a script that prints a warning
> >>> message. It will stay that way until openrc-1.0. OpenRc upstream
> >>> uses semantic versioning [2]. This means that as long as we are at
> >>> 0.x we have to keep things backward compatible.
> >>>
> >>
> >> ...why not?  As you've said yourself, nothing related to openrc uses
> >> /etc/init.d/functions.sh; if everything else in the tree is going to
> >> use the new gentoo-functions "lib", why wouldn't custom end-user
> >> scripts too?
> >>
> >> (again, scanned the bug, didn't see anything relevant to this)
> > 
> > The relevance is that /etc/init.d/functions.sh is currently part of
> > OpenRc's public API, and semantic versioning has a very specific
> > description of how to deprecate functionality.
> 
> Why deprecate it?
> 
> I'm getting really irritated with the current trend of randomly renaming
> and movearounding things. All it does is confuse people, break existing
> setups and make documentation splitbrained (now you need to document two
> things, and half the old docs won't be aware of it ...)

See: http://article.gmane.org/gmane.linux.gentoo.project/3357

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature