[csw-maintainers] Samba 4

[slowfranklin]

Hi

Am 03.09.2013 um 11:50 schrieb Laurent Blume <laurent at opencsw.org>:
> 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.

Fast forward 2 years, fast forward 5 years. Versioned packages all over the place. Eg possibly CSWsamba, CSWsamba4, CSWsamba5, CSWsamba6. *blah*

We're *forced* to use verioned package names due to the lack of any usable catalog other then unstable.

>> 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 :-/

If it would be an automated process not su much. But I have no background in packaging and distribution managment.

>> 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?

I never suggested to *maintain* a stable catalog. I only came up with what is already described on the website and which is an automated process. But it seems that idea was already killed of for some reasons.

>> 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? :-)

You got it. :)
Adding another (default disabled) init/SMF manifest for the samba daemon is a non issue and easily be done once we have the package in good shape.

-slow