[csw-users] Samba 3.2.0 and 3.0.31 ?

Thu Jul 24 05:16:09 CEST 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, All.

	As non-active as I am on this list (Mainly due to me still getting as
much experience with Blastwave before I completely dive in), I have to
agree with Dennis 100% on this. There's no reason to state what I agree
upon as Dennis has explained his stand on this to the Nth degree. While
I'm a big fan of minimalism, the fact that disk space and other system
resources that have so many times in the past been referred to as
"bloat" doesn't come in to play _NEAR_ as much as it used to.

	Coming from a BSD background, I'm used to many, _MANY_ applications
diced into separate applications which are installed based upon
dependencies and/or whatever the admin decides to install. This is great
in the idea that you can choose and be as minimalistic as possible.
However, these are only packed with options because they are source
builds being compiled then. In other words, if you want fancy, detailed,
minimalistic installs, build from source. Otherwise, a package should
house a complete application...

	Just my two cents.

Regards,
Janky Jay, III

Dennis Clarke wrote:
> On Wed, Jul 23, 2008 at 7:50 PM, Trygve Laugstøl <trygvel at blastwave.org> wrote:
>> Dennis Clarke wrote:
>>> On Wed, Jul 23, 2008 at 6:58 PM, Trygve Laugstøl <trygvel at blastwave.org>
>>> wrote:
>>>> Dennis Clarke wrote:
>>>>> I hate to beat a dead horse .. but I have Samba 3.0.31 and 3.2.0 built
>>>>> and tested with Windows XP and Vista. I'm not too sure how to get
>>>>> these things out to the world other than to post the packages. I have
>>>>> no reason or desire to break this thing up into 8 itty bitty packages
>>>>> with 20 files in some and 200 in others. That is a waste of time and
>>>>> energy.
>>>>>
>>>> [snipping noise]
>>>>
>>>>> anyways ... the upshot of all this is .. I have gottent to be fairly
>>>>> adept at building a nice Samba package and I feel that it should be
>>>>> available *somewhere* and somehow.
>>>>>
>>>>> Thoughts ?
>>>> The package is split up into different packages, shouldn't that make it
>>>> pretty easy to do that with the new package as well?
>>> Is not split up.  As for "easy" .. no it is not. It is a pain that can
>>> take hours to do and it needs to be done manually because the package
>>> contents do not line up from version to version. At least not very
>>> well.
>> It is split up:
>>
>> http://www.blastwave.org/packages/samba
>> http://www.blastwave.org/packages/samba_client
>> http://www.blastwave.org/packages/samba_common
>> http://www.blastwave.org/packages/samba_doc
>> http://www.blastwave.org/packages/samba_lib
>> http://www.blastwave.org/packages/samba_libdev
>> http://www.blastwave.org/packages/samba_swat
>> http://www.blastwave.org/packages/samba_wb
> 
> Before you read any further, please know that I hold you in a place of
> respect and I know what your skill set is. This is not an appeal to
> your intellectual vanity but merely my way of letting you know up
> front that I *value* your input.
> 
> Also, please see item #20 ( Proof by Tradition ) on this page
>      http://www.javaranch.com/fallacy.jsp
> 
> So my position on this is based on the following assertions :
> 
> 1 ) The Samba project seems to know what they are doing and the source site
> for this samba software always performs an installation that includes all
> of the 630+ files with documentation, libraries ( both static and dynamic )
> as well as the binaries required and a few other things too. This "installation"
> of samba is complete and there is no option for man pages only or fractional
> installation.  I call this "samba". When I create a SVR4 package that adds
> even more stuff to the "samba" package I then have a Solaris SVR4 compliant
> package with an rc2.d init script and package metadata added. The result of
> my months of effort then is "samba" as defined by the Samba project themselves
> as well as a "Solaris ready samba package" which is good to use.
> 
> 2) I can not justify nor find reasonable cause to break up the "samba" package
> as defined by the Samba Project into some arbitrary number of smaller
> non-overlapping packages.  The only things I have heard are the argument of
> Tradition ( see #20 on that link above ) or perhaps the "bloat" argument.
> 
> Both are fully open to rational debate and discussion of course.
> 
> I can create a single unified package just fine, and I have. The split
> up that you see above has no basis in justification other than
> "because Debian does it this way". There is no valid reason for it
> anymore that I can see. I wish that "bloat" were a reasonable concern
> but I just don't see the issue unless people are annoyed by 600+ files
> when they only need 5. I am not concerned with someone annoyance when
> the Samba project defines the software package called "samba" as a
> 630+ file installation.
> 
> Here comes a possible "8) Proof by Straw Man (Straw Man Fallacy)" :
> People do not drive stripped down sports cars all over the place ..
> they like fully bloated cars with leather, DVD players and air
> conditioning. Probably because they are stuck in them for hours at a
> time. Personally I like stripped down to the ground sports cars (
> Ferrari F40 ) but that is just me. When it comes to Solaris I no
> longer install just core cluster and then add stuff I *need*. Mostly
> because I am swimming in memory and hard drive space and the
> operatiuon of the machine is more important to me. I do not subscribe
> to the Microsoft notion of "minimized attack surface" by installing
> the bare minimum in a Solaris machine.
> 
> In fact, please see the following :
> 
>     http://www.blastwave.org/dclarke/snv_81_minimal.txt
> 
> That shows that I have done some experiments with a very very small
> install footprint with Solaris and still kept ZFS and Zones and the
> ability to have mirrors etc. It all worked.
> 
> But it wasn't any fun.
> 
>>>> The biggest argument people have is that it drag in so many dependencies
>>>> and lumping all of it into a gigantic package is going to pull in truckloads
>>>> of stuff that people doesn't need.
> 
> yeah .. that bugs me but .. it isn't my package. The Samba people
> define what samba is and not me. The user may want something different
> and it may have made sense in 1998 but I just have a hard time
> wrapping my head around the split up.
> 
>>> You install it and you get the whole package based on the build from
>>> the sources. When you do the build and the install it you get samba ..
>>> all of it .. not bits and pieces.
>> See above.
> 
> Not good enough.
> 
> What you are describing is called "gorilla bureaucracy" in that you
> expect people to conform to some rule without any valid and current
> contextual justification.
> 
>>>> There are applications using only the
>>>> libraries and people only using the client side.
>>> So what ?
>> You asked for an opinion and you got one. Just because it doesn't agree with
>> you doesn't give you the right to say "so what" without justification.
> 
> Hence my long reply :-)
> 
>> If you need help there are maintainers willing to do so, just put it in SVN and
>> I and others can help out.
> 
> Well I was more concerned about the long road ahead and if this will
> continue or not. If I were to package up this Samba then I woukd do so
> and release it for Solaris 10 upwards and possibly OpenSolaris.   I
> don't see any reason to build on Solaris 8 other than the golden ABI
> rule. That rule stands and it is a damn good rule. It simply isn't
> somethng that I ( or much of anyone else ) runs anymore.  Sort of like
> Windows NT on the DEC Alpha. A damn fine way to work but not very
> popular anymore.  This may be "18) Proof by Vote (Bandwagon Fallacy)"
> 
>>> So now you install samba and you get all that in one shot.
>>>
>>> disk is cheap.
>>> You install the package .. and it works.
>> I was just saying that it is a big reason for not using blastwave as it
>> leads to "bloat" etc. This is what the users are saying, me included at
>> least for packages where it should be possible to split it up. Having good
>> control over your dependencies leads to higher quality packages in the long
>> term.
> 
> Does it?
> 
> What do you mean by "quality" and what do you mean by "long term"?
> 
> Dennis
> _______________________________________________
> users mailing list
> users at lists.blastwave.org
> https://lists.blastwave.org/mailman/listinfo/users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIh/P5GK3MsUbJZn4RAucWAJsEOO/Uy6qOyPn6+oNCOAxGGAw+cgCcDYrW
X1VjroPOnHaMaG05IntodMI=
=FUW2
-----END PGP SIGNATURE-----