Re: [csw-maintainers] Samba 4
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. ::.
