[linux-cifs-client] First alpha of new cifs-utils package

[Christian PERRIER]

Quoting Jeff Layton (jlayton at samba.org):

> ...and went ahead and cut a first release and dropped it into the
> directory there. I've decided to change the version numbering scheme a
> bit and plan to make the first release "4.0". Since we're splitting off
> from samba3, starting the versions with a higher number than 3.x seems
> like it'll make it easier for people packaging samba. That should help
> ensure the new packages supercede any packages based on the samba 3.x
> releases. I'm flexible on this however, so if anyone thinks this'll be
> a problem, let me know.

That could be much appreciated if you go this way.

Speaking with the Debian maintainer had (or, say, packaging team
representative), I think we will use this opportunity to get rid of
the "smbfs" binary package name, which we still carry for historical
reasons (and lazyness) even though we don't provide mount.smbfs
anymore.

The plan for Debian (and Ubuntu as side effect) could be more or less
the following:

- create a "cifs-utils" or "cifsprogs" package based on your first
published release (using "cifsprogs" would make things parallel to
packages such as "e2fsprogs", "xfsprogs", "ntfsprogs"...to name only
those I have on my own machine). Make it "Provides: smbfs" so that
packages depending on "smbfs" are not broken.

- In samba, turn smbfs into a transition package (thus empty) that
only "Depends: cifsprogs" (thus allowing smooth transition to users
that have smbfs installed)

- Report bugs to packages depending on smbfs to have their
dependencies changed (If some do. I haven't checked this)

- Drop the transition package when no more package depends on smbfs
and after a release cycle.

(this is to be polished with Steve who's much more clever with
handling such things than me).

So, the versioning is not mandatory for us as we will switch the
namespace...but it could make life easier for other distros if they
already changed the package name.

Maybe think about the package naming if you think that having things
aligned with other FS utilities packages is good or not. Though, I
haven't verified that "e2fsprogs" or "xfsprogs" are named that way by
their respective upstream.