On Tue, Feb 12, 2013 at 07:01:33PM +0100, Goffredo Baroncelli wrote: > On 02/12/2013 06:37 PM, Filipe Brandenburger wrote: > > Hi, > > > > On Tue, Feb 12, 2013 at 8:39 AM, David Sterba <dsterba@xxxxxxx> wrote: > >> +# For backward compatibility, 'btrfs' changes behaviour to fsck if it's named 'btrfsck' > >> +btrfsck: btrfs > >> + @echo " [CP] $@" > >> + $(Q)cp btrfs btrfsck > >> + > > > > I think the idea was that btrfsck becomes a link (either symbolic or > > hardlink works) to btrfs... > > > > Maybe just replace cp with ln? > > I agree with Filipe, or even a script is reasonable. So we have only one > binary to update, and we avoid the risk to have a version mismatch > between btrfsck and btrfs. This could lead to a different behaviour > when the user call btrfsck instead btrfs. Finally this could save some > bytes of space. Ok, I'll replace it with a hardlink. A symlink is not reliable (cannot be copied without breaking the path). > Anyway my opinion would be to left this kind to decision to the > distribution. We (as upstream) should only remove the old btrfsck and > issue an WARNING/REMARK in the release note to notify this change. > Unfortunately btrfsck is old; now we must provide an alternative file to > overwrite this binary in order to avoid the mismatch above when the user > is used to recompile the binary from the source. A warning is a good idea and it will start a deprecation period of btrfsck as separate utility. Unil some point in future, I'd rather stay conservative and let it exist. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
