Re: [csw-maintainers] Samba 4

2013-09-03 Thread Peter FELECAN
Laurent Blume laur...@opencsw.org writes:

 On 2013-09-02 7:15 PM, slowfranklin wrote:
 Well, Samba 4.0 is the current *stable* Samba release series. 

 Yup, but 3.6 is still actively maintained (and 3.5 too for security,
 actually).

 But we can tell people: why are you sticking with 3.x when upgrading
 to 4.y is a non issue?

 «Because my boss says so», «because my software is only supported for
 Samba 3», «because we have a recertifying process that takes too long».

 Believe me, a major version change is an issue that should not be
 underestimated just because it *should* work (and I'm not an advocate of
 just staying on old unmaintained versions, but staying on old,
 *supported* version does makes sense).

This is a recurrent argument. If it had prevailed we still provide
packages for Solaris 8. Fortunately it had not. A sticky argument also:
look how difficult is to stop providing packages for Solaris 9 which is
not maintained by its supplier. Lets the enterprises re-certify their
platforms as they still have more resources than we have. 

Note that Solaris 10 U11 provides Samba 3.6.8

As a reminder, our goal is to provide an up to date, i.e. state of the
art, package set for Solaris 10 and greater. Samba 4.0.9 corresponds to
this definition.
-- 
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread slowfranklin

Am 03.09.2013 um 09:24 schrieb Peter FELECAN pfele...@opencsw.org:

 Laurent Blume laur...@opencsw.org writes:
 
 On 2013-09-02 7:15 PM, slowfranklin wrote:
 Well, Samba 4.0 is the current *stable* Samba release series. 
 
 Yup, but 3.6 is still actively maintained (and 3.5 too for security,
 actually).
 
 But we can tell people: why are you sticking with 3.x when upgrading
 to 4.y is a non issue?
 
 «Because my boss says so», «because my software is only supported for
 Samba 3», «because we have a recertifying process that takes too long».
 
 Believe me, a major version change is an issue that should not be
 underestimated just because it *should* work (and I'm not an advocate of
 just staying on old unmaintained versions, but staying on old,
 *supported* version does makes sense).
 
 This is a recurrent argument. If it had prevailed we still provide
 packages for Solaris 8. Fortunately it had not. A sticky argument also:
 look how difficult is to stop providing packages for Solaris 9 which is
 not maintained by its supplier. Lets the enterprises re-certify their
 platforms as they still have more resources than we have. 
 
 Note that Solaris 10 U11 provides Samba 3.6.8
 
 As a reminder, our goal is to provide an up to date, i.e. state of the
 art, package set for Solaris 10 and greater. Samba 4.0.9 corresponds to
 this definition.


the debate is not so much if we want a Samba 4 package, but how we name it.

I'd simply like to avoid a version suffix if possible. If that is not possible 
for valid reason, and in the context of OpenCSWs current state of branches imo 
Laurent has brought up valid concerns, then lets keep the current design of the 
Samba 4 package recipe and add a 4 suffix to the packages. There are several 
other packages that have versioned names too.

I'd prefer to have a unstable catalog that could be used for its purpose and a 
testing catalog that offered a set of older, stable packages, but afaict 
testing is far from that.

What happened to the automatic package promotion from unstable to testing that 
is descibed on the website? Eg 
http://wiki.opencsw.org/releases-and-staging#toc20:

  Packages from unstable/ that have no bugs filed against them, are promoted 
to testing/

If we had something like that we could easily honor Laurent's concerns by going 
ahead and adding a unversioned Samba 4 package (ie no 4 suffix) and file a bug 
against it preventing promotion.

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread Laurent Blume

On 03/09/13 09:24, Peter FELECAN wrote:

This is a recurrent argument. If it had prevailed we still provide
packages for Solaris 8.


Let me repeat it again, in the hope you will read it this time: I am 
advocating only keeping SUPPORTED VERSIOBS.


snip irrelevant comments about an obsolete unsupported system


Note that Solaris 10 U11 provides Samba 3.6.8


It's patched to 3.6.15, actually. And I've pushed 3.6.18 to OpenCSW.

I am using OpenCSW's Samba on Solaris 10 because Sun and now Oracle 
update path is a complete blackhole, and impossible to predict or 
influence. They are updating it now, but who knows why or for how long?



As a reminder, our goal is to provide an up to date, i.e. state of the
art, package set for Solaris 10 and greater. Samba 4.0.9 corresponds to
this definition.


Gee, thank you very much. That had just completely escaped me.
But luckily, Samba 3.6.18 also corresponds to that definition, just as 
GnuPG 1.4.14 and MySQL 5.5.33.


Peter, I am asking you to please make more effort to read other people's 
posts and not distort their meaning.


Thanks.

Laurent



___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread slowfranklin

Am 02.09.2013 um 18:45 schrieb Laurent Blume laur...@opencsw.org:

 On 2013-09-02 7:15 PM, slowfranklin wrote:
 Well, Samba 4.0 is the current *stable* Samba release series. 
 
 Yup, but 3.6 is still actively maintained (and 3.5 too for security,
 actually).

I know.

 But we can tell people: why are you sticking with 3.x when upgrading to 4.y 
 is a non issue?
 
 «Because my boss says so», «because my software is only supported for
 Samba 3», «because we have a recertifying process that takes too long».
 
 Believe me, a major version change is an issue that should not be
 underestimated just because it *should* work (and I'm not an advocate of
 just staying on old unmaintained versions, but staying on old,
 *supported* version does makes sense).

This argument would effectively prevent any major version upgrade in unstable, 
because for every upgrade someone may have concerns.
You're tracking an unstable catalog. The lack of a stable catalog is bad enough 
off itself, but if we let that influence too much the way we add packages to 
the unstable catalog, we make things worse, not better.

Don't get me wrong, I fully understand your concerns and whole heartedly agree 
that I wouldn't want my production Samba 3.6 installation being upgraded 
without need. If others agree I'm open to use a 4 suffix for the package. 

 
 In Samba 4 you still have smbd, nmdb, winbindd. Additionally you have
 a new binary named `samba' which is the one used for the whole AD
 stuff. But you can still run only smbd and friends. The updated
 package will use the exiting init/SMF stuff so it will only run smbd,
 nmdb and possibly winbindd by default. Anybody who wants to run a AD
 DC must disable these and roll his own mechanims for starting `samba'
 (until we get around adding a default disabled SMF manifest or
 similar).
 
 How is this started at boot if not using init or SMF?

As I was trying to explain repeatedly, it is NOT started at boot. It refers to 
the `samba' binary.

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread Laurent Blume

On 03/09/13 11:29, slowfranklin wrote:

I'd simply like to avoid a version suffix if possible. If that is not
possible for valid reason, and in the context of OpenCSWs current
state of branches imo Laurent has brought up valid concerns, then
lets keep the current design of the Samba 4 package recipe and add a
4 suffix to the packages. There are several other packages that have
versioned names too.


To be honest, I'm not sure I understand the rationale for removing the 
version suffix (I'm not the one who named the current Samba 3 packages, 
I'd have kept the number).


What's better without a version suffix? Either way look good to me from 
the user viewpoint, but one makes transitions harder for the maintainers.


Of course, that's for critical tools, it's not a casual user that will 
install Samba in the first place, I expect one to have some knowledge of it.


Now since we're really talking about having as recent as possible 
packages for Solaris 10 - well, someone who is still using Solaris 10 
must already have some incentive to stay on older versions, else they'd 
have switched to a more recent OS.
So for some software like Samba which can have a lot of complicated 
interactions, I will advocate strongly keeping the older versions as 
long as they are supported and it is reasonably doable.
That applies to MySQL, for which I will keep 5.5 running even when we 
finally have 5.6 (I'd have kept 5.1 if it had been done).


Some other programs which are much less critical, of course, I believe 
they can be upgraded, and without keeping a version suffix.
Say, eg, vim: a casual user can install that, and the exact major 
version won't have much influence.



I'd prefer to have a unstable catalog that could be used for its
purpose and a testing catalog that offered a set of older, stable
packages, but afaict testing is far from that.

What happened to the automatic package promotion from unstable to
testing that is descibed on the website? Eg
http://wiki.opencsw.org/releases-and-staging#toc20:

Packages from unstable/ that have no bugs filed against them, are
promoted to testing/

If we had something like that we could easily honor Laurent's
concerns by going ahead and adding a unversioned Samba 4 package (ie
no 4 suffix) and file a bug against it preventing promotion.


Yes, the path forward needs to be defined, but I'm afraid it'll be more 
an issue of resources than anything else :-/


Laurent
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread Laurent Blume

On 03/09/13 11:40, slowfranklin wrote:


This argument would effectively prevent any major version upgrade in
unstable, because for every upgrade someone may have concerns.


That simply not true. If you must have colliding binaries, you can keep 
two packages at different versions, one marked incompatible with the other.

Of course, they must have different names, but that's a detail.


You're
tracking an unstable catalog. The lack of a stable catalog is bad
enough off itself, but if we let that influence too much the way we
add packages to the unstable catalog, we make things worse, not
better.


Actually, thinking about it, I'm starting to believe that only 
unstable and experimental should be kept, the former renamed to 
something more neutral.
Resources are stretched too thin. Can we maintain a stable repository? 
Look at how many people are active here. A dozen? With a huge 
responsibility on a handful, Dago, Maciej, Bonivart, Yann?
The popularity of Solaris is not growing. We've got to plan with the 
current resources. Looking at Fedora, at Debian for inspiration is good. 
Trying to do exactly as they do is not.



As I was trying to explain repeatedly, it is NOT started at boot. It
refers to the `samba' binary.


Yes, I got that. So you mean, right now, you need to run that samba 
command manually, and later, you will have an SMF for it? Did I get it 
correctly now? Or am I still too dense? :-)


Laurent


___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread Peter Bonivart
On Tue, Sep 3, 2013 at 12:39 PM, slowfranklin slowfrank...@opencsw.org wrote:
 Fast forward 2 years, fast forward 5 years. Versioned packages all over the 
 place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5, CSWsamba6. *blah*

I don't see that we would ever have more than two at the same time
spanning all our catalogs, certainly not in any single catalog.

I think it's easier both for us and the users to have this system when
it comes to the large titles like samba, apache and so on. No one
would like to accidentally upgrade to something that is not compatible
and for us to create complicated processes to avoid this is
unnecessary work in my opinion.

/peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread slowfranklin

Am 03.09.2013 um 13:26 schrieb Laurent Blume laur...@opencsw.org:

 On 03/09/13 12:39, slowfranklin wrote:
 Fast forward 2 years, fast forward 5 years. Versioned packages all
 over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5,
 CSWsamba6. *blah*
 
 Yes? So what? I'm genuinely puzzled now. How is that a problem? Personal 
 hatred for numbers? :-)

Well, we'll also need versioned libraries like CSWsamba4-libwclient0, 
CSWsamba4-libsmbclient0.

But other then a vague feeling that versioned names are a blatant workaround 
for a problem that is arising from abusing a rolling catalog, no, I can't 
substantiate my concerns.

 If it's just against your personal taste, well, okay, de gustibus et 
 coloribus non disputandum, but it doesn't make it a *bad* technical decision: 
 it avoids problems instead of creating them, So, why not?
 
 We're *forced* to use verioned package names due to the lack of any
 usable catalog other then unstable.
 
 Well, since others do just that, package versioning, it must not be so wrong.

Well, since others (Debian, Fedora, ArchLinux) were all going for an inplace 
upgrade, I considered that the obvious choice for an unstable rolling catalog.

But we now have two votes for using the 4 suffix, so be it. :)

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread Laurent Blume

On 03/09/13 14:45, slowfranklin wrote:

Well, we'll also need versioned libraries like CSWsamba4-libwclient0,
CSWsamba4-libsmbclient0.


For that specific library, actually, it should not be needed, bad
example ;-)
Okay, I see what you mean, but I don't see it as a problem: mgar, pkgchk 
and friends make it all too easy to handle.



Well, since others (Debian, Fedora, ArchLinux) were all going for an
inplace upgrade, I considered that the obvious choice for an unstable
rolling catalog.


At least for Debian, that's not the case: they're planning on phasing 
out Samba 3, but it's not close at all. They only do it in experimental 
at this point. And for having worked with the Debian Samba maintainer, I 
can assure you the switch is being spread over years, I would say maybe 
even a decade, with both packages being available together in various 
forms during this time (experimental, backports, then .



But we now have two votes for using the 4 suffix, so be it. :)


In any case, there's nothing set in stone for 4 at this point, since 
it's not usable yet, so it looks like a safe point to start :-)


Laurent
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread slowfranklin

Am 03.09.2013 um 15:49 schrieb Laurent Blume laur...@opencsw.org:

 On 03/09/13 14:45, slowfranklin wrote:
 Well, we'll also need versioned libraries like CSWsamba4-libwclient0,
 CSWsamba4-libsmbclient0.
 
 For that specific library, actually, it should not be needed, bad
 example ;-)

No? Why not?! Otherwise we'd have the same package (eg CSWlibwbclient0) built 
from two different recipes uploaded to the catalog. Am I missing sth?

 Okay, I see what you mean, but I don't see it as a problem: mgar, pkgchk and 
 friends make it all too easy to handle.
 
 Well, since others (Debian, Fedora, ArchLinux) were all going for an
 inplace upgrade, I considered that the obvious choice for an unstable
 rolling catalog.
 
 At least for Debian, that's not the case: they're planning on phasing out 
 Samba 3, but it's not close at all.

Hold on. I was not referring to what Debian as a whole achieves by using 
different catalogs/distributions or backports. I said obvious choice for an 
unstable rolling catalog which would be unstable/sid in the Debian case. And 
apparently Debian is going to use an unversioned Samba 4 package in sid.

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread Peter FELECAN
Peter Bonivart boniv...@opencsw.org writes:

 On Tue, Sep 3, 2013 at 12:39 PM, slowfranklin slowfrank...@opencsw.org 
 wrote:
 Fast forward 2 years, fast forward 5 years. Versioned packages all
 over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5,
 CSWsamba6. *blah*

 I don't see that we would ever have more than two at the same time
 spanning all our catalogs, certainly not in any single catalog.

 I think it's easier both for us and the users to have this system when
 it comes to the large titles like samba, apache and so on. No one
 would like to accidentally upgrade to something that is not compatible
 and for us to create complicated processes to avoid this is
 unnecessary work in my opinion.

We currently have python, python27, python3 and almost had python34 but
escaped that with an astute feint.

We had gcc2, gcc3 and gcc4 (well they were of my initiative) but they
are fortunately history.
-- 
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread Dagobert Michelsen
Hi Slow,

Am 03.09.2013 um 16:43 schrieb slowfranklin slowfrank...@opencsw.org:

 I propose the following changes to the Samba 4 recipe:
 
 o package set:
 
   CSWsamba4
   CSWsamba4-dc ... Samba 4 AD DC component, can be installed 
 without CSWsamba4
   CSWsamba4-client
   CSWsamba4-winbind... winbind stuff including NSS am PAM modules
   CSWsamba4-common ... common files
   CSWsamba4-libs   ... Samba libraries
   CSWsamba4-dc-libs... Samba AD DC libraries
   CSWsamba4-nss-system-links
   CSWsamba4-pam-system-links
 
 o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will 
 still be coming
  from Samba 3, Samba 4 will use private versions of these libs
 
 o the main  package is split into libs and common, because it seems in Samba4 
 libraries
  like libsmbclient are linked with tons of private Samba libs, so we really 
 want
  these private libs to be available as a seperate package otherwise the whole
  Samba packaged would be pulled in when someone installs libsmbclient
 
 o iirc running a Samba4 AD DC means you can't run the fileserver daemon smbd 
 on the
  sambe host. For a AD DC you install CSWsamba4-dc, for a fileserver you 
 install CSWsamba4.
  Nice and small packages.
 
 o no package CSWsamba4-swat, because SWAT is dead
 o no package CSWsamba4-dev, because we don't package any public library
 
 For reference, this is our current set for Samba 4:
 
   PACKAGES += CSWsamba4
   PACKAGES += CSWsamba4-client
   PACKAGES += CSWlibnetapi0

^^

   PACKAGES += CSWlibnss-winbind1
   PACKAGES += CSWsamba4-dev
   PACKAGES += CSWsamba4-swat
   PACKAGES += CSWsamba4-winbind
 
 These are the Samba 3 packages:
 
   PACKAGES += CSWsamba
   PACKAGES += CSWsamba-client
   PACKAGES += CSWlibsmbclient0
   PACKAGES += CSWlibwbclient0
   PACKAGES += CSWlibnetapi0

Are these two packages from Samba 4, Samba 3, or should they be in different 
pathes?

   PACKAGES += CSWlibsmbsharemodes0
   PACKAGES += CSWlibtdb1
   PACKAGES += CSWsamba-nss
   PACKAGES += CSWsamba-nss-system-links
   PACKAGES += CSWsamba-pam-system-links
   PACKAGES += CSWlibtevent0
   PACKAGES += CSWsamba-dev
   PACKAGES += CSWsamba-swat
   PACKAGES += CSWsamba-winbind
 
 Only Samba 3 package consumed by other packages is CSWlibsmbclient0 (by 
 CSWgnomevfs2 and CSWvlc).


Best regards

  -- Dago

-- 
You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process. - xkcd #896



smime.p7s
Description: S/MIME cryptographic signature
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.

Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread slowfranklin
Hi Dago

Am 03.09.2013 um 16:46 schrieb Dagobert Michelsen d...@opencsw.org:

 Hi Slow,
 
 Am 03.09.2013 um 16:43 schrieb slowfranklin slowfrank...@opencsw.org:
 
 I propose the following changes to the Samba 4 recipe:
 
 o package set:
 
  CSWsamba4
  CSWsamba4-dc ... Samba 4 AD DC component, can be installed 
 without CSWsamba4
  CSWsamba4-client
  CSWsamba4-winbind... winbind stuff including NSS am PAM modules
  CSWsamba4-common ... common files
  CSWsamba4-libs   ... Samba libraries
  CSWsamba4-dc-libs... Samba AD DC libraries
  CSWsamba4-nss-system-links
  CSWsamba4-pam-system-links
 
 o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will 
 still be coming
 from Samba 3, Samba 4 will use private versions of these libs
 
 o the main  package is split into libs and common, because it seems in 
 Samba4 libraries
 like libsmbclient are linked with tons of private Samba libs, so we really 
 want
 these private libs to be available as a seperate package otherwise the whole
 Samba packaged would be pulled in when someone installs libsmbclient
 
 o iirc running a Samba4 AD DC means you can't run the fileserver daemon smbd 
 on the
 sambe host. For a AD DC you install CSWsamba4-dc, for a fileserver you 
 install CSWsamba4.
 Nice and small packages.
 
 o no package CSWsamba4-swat, because SWAT is dead
 o no package CSWsamba4-dev, because we don't package any public library
 
 For reference, this is our current set for Samba 4:
 
  PACKAGES += CSWsamba4
  PACKAGES += CSWsamba4-client
  PACKAGES += CSWlibnetapi0
 
 ^^

That is the current gar recipe which I'm going to modify, ie drop the libs. At 
the top of my mail I list the packages I would like to build from a modified 
Samba 4 gar recipe.

 
  PACKAGES += CSWlibnss-winbind1
  PACKAGES += CSWsamba4-dev
  PACKAGES += CSWsamba4-swat
  PACKAGES += CSWsamba4-winbind
 
 These are the Samba 3 packages:
 
  PACKAGES += CSWsamba
  PACKAGES += CSWsamba-client
  PACKAGES += CSWlibsmbclient0
  PACKAGES += CSWlibwbclient0
  PACKAGES += CSWlibnetapi0
 
 Are these two packages from Samba 4, Samba 3, or should they be in different 
 pathes?

For now, these libs will not be part of the Samba 4 packages.

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-03 Thread Laurent Blume

On 03/09/13 16:04, slowfranklin wrote:

No? Why not?! Otherwise we'd have the same package (eg
CSWlibwbclient0) built from two different recipes uploaded to the
catalog. Am I missing sth?


Since from what we discussed, it's just the same lib being built as part 
of either v3 or v4, one of the two would be dropped without problem. 
It's not like the tools which do conflict. It's only a matter of 
selecting which to keep (probably something like v3 while v4 is settling 
down, then v4 when it's mature).



Hold on. I was not referring to what Debian as a whole achieves by
using different catalogs/distributions or backports. I said obvious
choice for an unstable rolling catalog which would be unstable/sid
in the Debian case. And apparently Debian is going to use an
unversioned Samba 4 package in sid.


Right now they have some unversioned and versioned package, both from v4 
in experimental, and from v3 and v4 respectively in unstable. Maybe it 
will go unversioned at some point, but they're apparently far from it.


For perspective, their stable/testing/unstable contain 4.0.0beta2 and 
experimental is 4.0.8. So it's not what we're discussing here either. 
We're planning for 4.1! They won't use that for *years*.


Laurent
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread Laurent Blume

On 2013-09-03 4:43 PM, slowfranklin wrote:
 o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will 
 still be coming
   from Samba 3, Samba 4 will use private versions of these libs

I think you don't need libsmbclient, at all. Like you noted, only
gnomevfs depends on it: no Samba binary uses it. So, no need for even a
private one; libnetapi appears to be the same case.
I see the Debian packages for v4 also have a libsmbclientraw, but that's
apparently a different lib, since their libsmbclient (without raw) do
switch from 3.6 to 4.0 in experimental. Do you see that one too?

 o the main  package is split into libs and common, because it seems in Samba4 
 libraries
   like libsmbclient are linked with tons of private Samba libs, so we really 
 want
   these private libs to be available as a seperate package otherwise the whole
   Samba packaged would be pulled in when someone installs libsmbclient

Can you list them? I'm a bit surprised that this libsmbclient would have
more dependencies, since it's supposed to be the same.

Laurent.


___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread slowfranklin
 o the main  package is split into libs and common, because it seems in 
 Samba4 libraries
 like libsmbclient are linked with tons of private Samba libs, so we really 
 want
 these private libs to be available as a seperate package otherwise the whole
 Samba packaged would be pulled in when someone installs libsmbclient
 
 Can you list them? I'm a bit surprised that this libsmbclient would have
 more dependencies, since it's supposed to be the same.
 
 This is from git master HEAD, built on Solaris 11.1 with this simple 
 configure invocation:
 
 $ ./configure \
--prefix=/opt/samba \
--with-ads \
--with-shared-modules=vfs_zfsacl

fwiw, you also need the fix I attached to this PR:
https://bugzilla.samba.org/show_bug.cgi?id=10112

As an alternative you can prefix the configure invocation with 
LDFLAGS=-RLIBDIR.

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread slowfranklin

Am 03.09.2013 um 19:05 schrieb Laurent Blume laur...@opencsw.org:

 
 On 2013-09-03 4:43 PM, slowfranklin wrote:
 o CSWlibwclient, CSWlibsmbsharemodes, CSWlibsmbclient and CSWlibnetapi will 
 still be coming
  from Samba 3, Samba 4 will use private versions of these libs
 
 I think you don't need libsmbclient, at all. Like you noted, only
 gnomevfs depends on it: no Samba binary uses it.

indeed. I'll see if they can be disabled in the build by configure.

 So, no need for even a
 private one; libnetapi appears to be the same case.
 I see the Debian packages for v4 also have a libsmbclientraw, but that's
 apparently a different lib, since their libsmbclient (without raw) do
 switch from 3.6 to 4.0 in experimental. Do you see that one too?

Yes:

$ ls /opt/samba/lib/libsmbclient-raw.so
/opt/samba/lib/libsmbclient-raw.so

 
 o the main  package is split into libs and common, because it seems in 
 Samba4 libraries
  like libsmbclient are linked with tons of private Samba libs, so we really 
 want
  these private libs to be available as a seperate package otherwise the whole
  Samba packaged would be pulled in when someone installs libsmbclient
 
 Can you list them? I'm a bit surprised that this libsmbclient would have
 more dependencies, since it's supposed to be the same.

This is from git master HEAD, built on Solaris 11.1 with this simple configure 
invocation:

$ ./configure \
--prefix=/opt/samba \
--with-ads \
--with-shared-modules=vfs_zfsacl

slow@solaris:~$ ldd /opt/samba/lib/libwbclient.so | grep /opt/samba
libwinbind-client.so =  /opt/samba/lib/private/libwinbind-client.so
libreplace.so = /opt/samba/lib/private/libreplace.so

slow@solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba
libsamba-util.so.0 =/opt/samba/lib/libsamba-util.so.0
libgssapi-samba4.so.2 = 
/opt/samba/lib/private/libgssapi-samba4.so.2
liblibsmb.so =  /opt/samba/lib/private/liblibsmb.so
libmsrpc3.so =  /opt/samba/lib/private/libmsrpc3.so
liblibcli_lsa3.so = /opt/samba/lib/private/liblibcli_lsa3.so
libsamba-security.so =  /opt/samba/lib/private/libsamba-security.so
liberrors.so =  /opt/samba/lib/private/liberrors.so
libsmbconf.so.0 =   /opt/samba/lib/libsmbconf.so.0
libtalloc.so.2 =/opt/samba/lib/private/libtalloc.so.2
libndr.so.0 =   /opt/samba/lib/libndr.so.0
libcli_smb_common.so =  /opt/samba/lib/private/libcli_smb_common.so
libgse.so = /opt/samba/lib/private/libgse.so
libutil_cmdline.so =/opt/samba/lib/private/libutil_cmdline.so
libndr-standard.so.0 =  /opt/samba/lib/libndr-standard.so.0
libdcerpc-samba.so =/opt/samba/lib/private/libdcerpc-samba.so
libsmbregistry.so = /opt/samba/lib/private/libsmbregistry.so
libsecrets3.so =/opt/samba/lib/private/libsecrets3.so
libtevent.so.0 =/opt/samba/lib/private/libtevent.so.0
libutil_setid.so =  /opt/samba/lib/private/libutil_setid.so
libreplace.so = /opt/samba/lib/private/libreplace.so
libkrb5-samba4.so.26 =  /opt/samba/lib/private/libkrb5-samba4.so.26
libroken-samba4.so.19 = 
/opt/samba/lib/private/libroken-samba4.so.19
libasn1-samba4.so.8 =   /opt/samba/lib/private/libasn1-samba4.so.8
libhcrypto-samba4.so.5 =
/opt/samba/lib/private/libhcrypto-samba4.so.5
libcom_err-samba4.so.0 =
/opt/samba/lib/private/libcom_err-samba4.so.0
libwind-samba4.so.0 =   /opt/samba/lib/private/libwind-samba4.so.0
libheimbase-samba4.so.1 =   
/opt/samba/lib/private/libheimbase-samba4.so.1
libhx509-samba4.so.5 =  /opt/samba/lib/private/libhx509-samba4.so.5
libwbclient.so.0 =  /opt/samba/lib/libwbclient.so.0
libsamba-credentials.so.0 = 
/opt/samba/lib/libsamba-credentials.so.0
libndr-samba.so =   /opt/samba/lib/private/libndr-samba.so
libcli_cldap.so =   /opt/samba/lib/private/libcli_cldap.so
libcliauth.so = /opt/samba/lib/private/libcliauth.so
libkrb5samba.so =   /opt/samba/lib/private/libkrb5samba.so
libsamba-sockets.so =   /opt/samba/lib/private/libsamba-sockets.so
libgensec.so.0 =/opt/samba/lib/libgensec.so.0
libasn1util.so =/opt/samba/lib/private/libasn1util.so
libsamba-hostconfig.so.0 =  /opt/samba/lib/libsamba-hostconfig.so.0
libndr-nbt.so.0 =   /opt/samba/lib/libndr-nbt.so.0
libtevent-util.so.0 =   /opt/samba/lib/libtevent-util.so.0
libsmb_transport.so =   /opt/samba/lib/private/libsmb_transport.so
libsamba3-util.so = /opt/samba/lib/private/libsamba3-util.so
libCHARSET3.so =/opt/samba/lib/private/libCHARSET3.so
libdcerpc-binding.so.0 =/opt/samba/lib/libdcerpc-binding.so.0
libndr-krb5pac.so.0 =   /opt/samba/lib/libndr-krb5pac.so.0
   

Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread slowfranklin
 slow@solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba
libsamba-util.so.0 =/opt/samba/lib/libsamba-util.so.0
 snip
 
 Okay, that's a lot, and really different.
 I gather you linked with -Bdirect?

Of course not. :)

 Can you do ldd with -v to see if they're direct deps?

http://pastebin.com/fJqGE4uh

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread Laurent Blume
On 2013-09-03 7:18 PM, slowfranklin wrote:
 indeed. I'll see if they can be disabled in the build by configure.

Don't bother too much if there's no option, just don't package them.
It's maybe even better: when we switch to it, it'll have been built
successfully many times over.

 Yes:
 
 $ ls /opt/samba/lib/libsmbclient-raw.so
 /opt/samba/lib/libsmbclient-raw.so

Okay, so that one would deserve its own little CSWlibsmbclient-raw package.

 slow@solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba
 libsamba-util.so.0 =/opt/samba/lib/libsamba-util.so.0
snip

Okay, that's a lot, and really different.
I gather you linked with -Bdirect?
Can you do ldd with -v to see if they're direct deps?

I'm going to investigate in a vboxed Debian.

Laurent



___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4, take 2, versioned packages

2013-09-03 Thread Laurent Blume
On 2013-09-03 7:49 PM, slowfranklin wrote:
 slow@solaris:~$ ldd /opt/samba/lib/libsmbclient.so | grep /opt/samba
libsamba-util.so.0 =/opt/samba/lib/libsamba-util.so.0
 snip

 Okay, that's a lot, and really different.
 I gather you linked with -Bdirect?
 
 Of course not. :)

Give it a try? And -z nolazyload for good measure?

 Can you do ldd with -v to see if they're direct deps?
 
 http://pastebin.com/fJqGE4uh

Really interesting.

Most of those are stuffed into the python-samba package on Debian sid:
http://packages.debian.org/sid/amd64/python-samba/filelist

Then in experimental, they've been moved to other places, such as:
http://packages.debian.org/experimental/amd64/libsmbd0/filelist

And yet, their libsmbclient 4.0.8 (the one in experimental) does not
depend on it that I can see, directly or not. There's something fishy.

Laurent
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Peter FELECAN
slowfranklin slowfrank...@opencsw.org writes:

 Thoughts?

Have you explored how Debian is doing this?
-- 
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Peter FELECAN
Laurent Blume laur...@opencsw.org writes:

 So there, how do you handle having packages with the same names but
 different origins? How will it impact people willing to stay on Samba
 3 for the time being?

Is there a reason to stay on Samba 3 when we will provide Samba 4?
-- 
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread slowfranklin

Am 02.09.2013 um 15:26 schrieb slowfranklin slowfrank...@opencsw.org:

 o drop the following packages:
 
CSWlibnss-winbind1  ... obsoleted by CSWsamba4-wb-clients

wrong. Correct:

 CSWlibnss-winbind1  ... obsoleted by CSWsamba-winbind

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Laurent Blume

On 02/09/13 17:27, Peter FELECAN wrote:

Is there a reason to stay on Samba 3 when we will provide Samba 4?


Is there a reason to switch to Samba 4 as long as Samba 3 is supported?


Have you looked at how Debian is doing it?

Laurent
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread slowfranklin
Hi

Am 02.09.2013 um 17:15 schrieb Laurent Blume laur...@opencsw.org:

 I propose the following changes to the Samba 4 recipe:
 
 o drop the 4 prefix, Fedora is considering the same [2]:
 
   As samba4 is a superset of Samba 3 packages in Fedora,
 
 What does that bit mean, exactly?

Samba 4 includes all Samba 3 binaries, libs and stuff and can be used a drop-in 
upgrade.

 Are you sure it applies here, ie, will Samba 4 really be a superset of Samba 
 3 packages?

More or less sure, yes.

 AFAIK, Fedora is a fast-running distro, they might not care as much for 
 stability.

Hey, it's targetting unstable, isn't it? :)
And the Samba 4 series is now already at 4.0.9 iirc with a first 4.1 about to 
be released soon, so we better catch up. :)

 we are also considering to discuss
   renaming samba4 back to samba. As all existing API and ABI for 
 smbd/nmbd/winbindd and
   libsmbclient library will be the same, the switch is not going to be 
 problematic. However,
   there is still need to stabilize code through beta and pre-releases before 
 doing that.
 
 o add the following packages:
 
 CSWsamba-common ... common files
 CSWsamba-lib... Samba libraries
 CSWsamba-dc ... the new Samba 4 AD DC stuff
 CSWsamba-dc-libs... libraries for CSWsamba-dc
 CSWlibtdb1  ... present in Samba 3, but missing in 4
 CSWlibwbclient0 ... present in Samba 3, but missing in 4
 CSWlibsmbclient0... present in Samba 3, but missing in 4
 CSWlibsmbsharemodes0... present in Samba 3, but missing in 4
 CSWsamba-nss-system-links   ... present in Samba 3, but missing in 4
 CSWsamba-pam-system-links   ... present in Samba 3, but missing in 4
 
 So there, how do you handle having packages with the same names but different 
 origins?

They have the same origin, not a different one, so it's simply a package 
upgrade. It's major revision bump, but it _should_ be compatible. So I propose 
we test it out if it really is.

 How will it impact people willing to stay on Samba 3 for the time being?

Switch to OpenCSW testing or don't upgrade unstable.

 The expactation is that users of the current Samba 3 package should
 be able to upgrade to Samba 4 in filesserver/NT DC mode without
 issues. Anyone who wants to run a AD DC must perform a manual setup
 as described in the Samba docs. There will be no support for
 auto-running the new samba AD controller process from init/SMF.
 
 Does that mean that process is run automatically by the regular SMF once it's 
 configured appropriately?

I said no support which was meant to express it's not run by anything.

-slow


___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread slowfranklin
Hi Peter,

Am 02.09.2013 um 17:25 schrieb Peter FELECAN pfele...@opencsw.org:

 slowfranklin slowfrank...@opencsw.org writes:
 
 Thoughts?
 
 Have you explored how Debian is doing this?

yes.

http://sources.debian.net/src/samba4/4.0.3%2Bdfsg1-0.1/debian/control

They're using a 4 suffix and iirc is they don't use and include smbd for file 
services at all, so it doesn't help us:
http://sources.debian.net/src/samba4/4.0.3%2Bdfsg1-0.1/debian/README.Debian

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread slowfranklin

Am 02.09.2013 um 17:47 schrieb Laurent Blume laur...@opencsw.org:

 On 02/09/13 17:27, Peter FELECAN wrote:
 Is there a reason to stay on Samba 3 when we will provide Samba 4?
 
 Is there a reason to switch to Samba 4 as long as Samba 3 is supported?

yes, customers are beginning to ask for this. Also, remember that AD DC thingy.

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Peter FELECAN
Laurent Blume laur...@opencsw.org writes:

 On 02/09/13 17:27, Peter FELECAN wrote:
 Is there a reason to stay on Samba 3 when we will provide Samba 4?

 Is there a reason to switch to Samba 4 as long as Samba 3 is supported?

Yes: new features, bugs corrected, fun, walking on the bleeding edge,
c

Heck, there is unstable, testing and kind of stable; people has the
freedom to choose.
-- 
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Laurent Blume

On 02/09/13 17:57, Peter FELECAN wrote:

Laurent Blume laur...@opencsw.org writes:


On 02/09/13 17:27, Peter FELECAN wrote:

Is there a reason to stay on Samba 3 when we will provide Samba 4?


Is there a reason to switch to Samba 4 as long as Samba 3 is supported?


Yes: new features, bugs corrected, fun, walking on the bleeding edge,
c

Heck, there is unstable, testing and kind of stable; people has the
freedom to choose.


So for that, the Debian way is not the right one?

I am confused by your conflicting statements.

Please clarify what you are cherry-picking from the Debian model.

Laurent

___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread slowfranklin

Am 02.09.2013 um 17:59 schrieb Peter FELECAN pfele...@opencsw.org:

 slowfranklin slowfrank...@opencsw.org writes:
 
 Hi Peter,
 
 Am 02.09.2013 um 17:25 schrieb Peter FELECAN pfele...@opencsw.org:
 
 slowfranklin slowfrank...@opencsw.org writes:
 
 Thoughts?
 
 Have you explored how Debian is doing this?
 
 yes.
 
 http://sources.debian.net/src/samba4/4.0.3%2Bdfsg1-0.1/debian/control
 
 They're using a 4 suffix and iirc is they don't use and include smbd for 
 file services at all, so it doesn't help us:
 http://sources.debian.net/src/samba4/4.0.3%2Bdfsg1-0.1/debian/README.Debian
 
 Thank you. That is what I wished to read...

digging into the Debian Samba 4 packaging effort some more, I found the most 
current source for the Samba package. Debian is now unto a merged (ie now 4 
suffix) naming scheme too. I faintly remebered reading this somewhere before 
but couldn't find it.

http://samba.2283325.n4.nabble.com/Building-Samba4-for-Debian-from-Git-td4649856.html
http://anonscm.debian.org/gitweb/?p=pkg-samba/samba.git;a=blob;f=debian/control;h=6105856b905bda0fc1a079a63f6071053327efb0;hb=refs/heads/samba_4.0

-slow
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Laurent Blume

On 02/09/13 17:47, slowfranklin wrote:

Samba 4 includes all Samba 3 binaries, libs and stuff and can be used a drop-in 
upgrade.


I've read that there are some configuration changes. Would an existing 
configuration just work with no change?



Hey, it's targetting unstable, isn't it? :)
And the Samba 4 series is now already at 4.0.9 iirc with a first 4.1 about to 
be released soon, so we better catch up. :)


Well, I'm all in favour of having Samba 4 :-)
But not at the cost of removing Samba 3 from unstable.

We have to be realistic here: testing on OpenCSW is not usable in any 
of the production environments I've worked in.
It's simply not upgraded enough. We're not a Linux distro, we don't have 
the resources to backport patches to older versions to keep them secure.
That's why I use unstable on my critical production boxes, with as much 
staging as I can.



They have the same origin, not a different one, so it's simply a package 
upgrade. It's major revision bump, but it _should_ be compatible. So I propose 
we test it out if it really is.


Ok, so it means it's no longer needed to provide it with Samba 3 once 
the version from v4 is delivered? Good.



Switch to OpenCSW testing or don't upgrade unstable.


We can't tell people that. Seriously.


I said no support which was meant to express it's not run by anything.


Okay, I still don't get it, I'll need to look at the thing :-)

Laurent

___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread slowfranklin

Am 02.09.2013 um 18:20 schrieb Laurent Blume laur...@opencsw.org:

 On 02/09/13 17:47, slowfranklin wrote:
 Samba 4 includes all Samba 3 binaries, libs and stuff and can be used a 
 drop-in upgrade.
 
 I've read that there are some configuration changes. Would an existing 
 configuration just work with no change?

Afaict yes.

https://wiki.samba.org/index.php/Samba_4.0_Features_added/changed#Upgrading

Upgrading a Samba 3 fileserver or NT4-style DC should just work, but of course 
we may need to test this.

I offer to work out the complete gar recipe based on this approach and then 
push packages to experimental where anybody interested can test em.

 Hey, it's targetting unstable, isn't it? :)
 And the Samba 4 series is now already at 4.0.9 iirc with a first 4.1 about 
 to be released soon, so we better catch up. :)
 
 Well, I'm all in favour of having Samba 4 :-)
 But not at the cost of removing Samba 3 from unstable.

Well, Samba 4.0 is the current *stable* Samba release series. 

 We have to be realistic here: testing on OpenCSW is not usable in any of 
 the production environments I've worked in.

Of course.

 It's simply not upgraded enough. We're not a Linux distro, we don't have the 
 resources to backport patches to older versions to keep them secure.
 That's why I use unstable on my critical production boxes, with as much 
 staging as I can.

+1

 They have the same origin, not a different one, so it's simply a package 
 upgrade. It's major revision bump, but it _should_ be compatible. So I 
 propose we test it out if it really is.
 
 Ok, so it means it's no longer needed to provide it with Samba 3 once the 
 version from v4 is delivered? Good.
 
 Switch to OpenCSW testing or don't upgrade unstable.
 
 We can't tell people that. Seriously.

But we can tell people: why are you sticking with 3.x when upgrading to 4.y is 
a non issue?

 I said no support which was meant to express it's not run by anything.
 
 Okay, I still don't get it, I'll need to look at the thing :-)

In Samba 4 you still have smbd, nmdb, winbindd. Additionally you have a new 
binary named `samba' which is the one used for the whole AD stuff. But you can 
still run only smbd and friends. The updated package will use the exiting 
init/SMF stuff so it will only run smbd, nmdb and possibly winbindd by default.
Anybody who wants to run a AD DC must disable these and roll his own mechanims 
for starting `samba' (until we get around adding a default disabled SMF 
manifest or similar).

-slow


___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Peter FELECAN
Laurent Blume laur...@opencsw.org writes:

 On 02/09/13 17:57, Peter FELECAN wrote:
 Laurent Blume laur...@opencsw.org writes:

 On 02/09/13 17:27, Peter FELECAN wrote:
 Is there a reason to stay on Samba 3 when we will provide Samba 4?

 Is there a reason to switch to Samba 4 as long as Samba 3 is supported?

 Yes: new features, bugs corrected, fun, walking on the bleeding edge,
 c

 Heck, there is unstable, testing and kind of stable; people has the
 freedom to choose.

 So for that, the Debian way is not the right one?

 I am confused by your conflicting statements.

 Please clarify what you are cherry-picking from the Debian model.

Not cherry picking really. As Slow wrote, Debian is going toward
a unique prefix supporting the latest stable upstream release. As
Fedora will.

As for the confusion and conflict I have no real comment at this point
in time. Seriously.
-- 
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.


Re: [csw-maintainers] Samba 4

2013-09-02 Thread Laurent Blume
On 2013-09-02 7:15 PM, slowfranklin wrote:
 Well, Samba 4.0 is the current *stable* Samba release series. 

Yup, but 3.6 is still actively maintained (and 3.5 too for security,
actually).

 But we can tell people: why are you sticking with 3.x when upgrading to 4.y 
 is a non issue?

«Because my boss says so», «because my software is only supported for
Samba 3», «because we have a recertifying process that takes too long».

Believe me, a major version change is an issue that should not be
underestimated just because it *should* work (and I'm not an advocate of
just staying on old unmaintained versions, but staying on old,
*supported* version does makes sense).

 In Samba 4 you still have smbd, nmdb, winbindd. Additionally you have
 a new binary named `samba' which is the one used for the whole AD
 stuff. But you can still run only smbd and friends. The updated
 package will use the exiting init/SMF stuff so it will only run smbd,
 nmdb and possibly winbindd by default. Anybody who wants to run a AD
 DC must disable these and roll his own mechanims for starting `samba'
 (until we get around adding a default disabled SMF manifest or
 similar).

How is this started at boot if not using init or SMF?

Laurent

___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.