Re: samba-3.2.5 missing

Re: samba-3.2.5 missing

[Tim Ellis]

> Calm down, thanks. I authored 3.2.5 for use in foonas which NAiL  
> pushed for me originally, and created the 3.2.7 build with active  
> directory support also for foonas - I tested this on multiple arches  
> and libcs in my target distributions and they work fine. I had  
> presumed when I started working on stuff here that I could maintain  
> my packages as I see fit and have ensured the older samba versions  
> have not included this functionality - and I followed the dev  
> guidelines on the wiki and moved to the upgrade - was this wrong?
>
> Anyway here is what I had been thinking about previously as you are  
> right, the changes are significant; create a separate samba-ads  
> build this weekend and revert the changes to samba. I will do this  
> at some point this weekend. Sorry if updating my packages upsets  
> you, if you don't see AD client support as a worthy feature just  
> dont use the new package at the other side of the weekend. Please  
> dont touch the samba builds - I had presumed as the maintainer of  
> this that other people wouldn't mess with it.
> Cheers,
>
> Tim
>
> Mike (mwester) wrote:
>
> > I'm going to re-create samba-3.2.5 as best as I can (it's way late,
> > maybe I'll screw it up and nobody's builds will work, who knows?),
>
> Screw it.  The changes are ******HUGE*****.   Can whoever removed the
> working 3.2.5 please put it back?  Thank you.
>
> Regards,
> Mike (mwester)

Re: samba-3.2.5 missing

[Mike (mwester)]

Tim Ellis wrote:
>> Calm down, thanks. I authored 3.2.5 for use in foonas which NAiL
>> pushed for me originally, and created the 3.2.7 build with active
>> directory support also for foonas - I tested this on multiple arches
>> and libcs in my target distributions and they work fine. I had
>> presumed when I started working on stuff here that I could maintain my
>> packages as I see fit

No.  Once you add a package, it is available for others to use, and you
need to take into consideration that others may, in fact, be using it!

>> and have ensured the older samba versions have
>> not included this functionality 

What does that mean?  Are you saying that because you added 3.2.5 that
you feel entitled to remove it, and replace it with one that adds
significant additional dependencies?  So I should set my
PREFERRED_VERSION back to a 3.0.x version of Samba?  That's ridiculous.

>> - and I followed the dev guidelines on
>> the wiki and moved to the upgrade - was this wrong?

Yes.  Let me expound on the problem.

3.2.5 included a specific set of features, with a specific set of
dependencies.

There are many cases where additional features should be enabled in a
package -- and it is often the case that these additional features can
cause trouble for other distros or users, perhaps because they have
dependencies that may be unbuildable (as in this case), or perhaps the
dependencies are undesirable (dbus pulling in all of the X libs was such
a case, recently), or perhaps the dependencies are just too big (opkg
had that problem).

S*** happens -- people have to move forward.  But there's no need to
break it for an entire distro; simply leaving the original version
pre-additional-dependencies about is sufficient to avoid it.  And that's
what's happened here -- 3.2.7 won't build because the dependencies won't
configure.  Yet neither can I go back to the old working 3.2.5 --
because it was REMOVED!

I further suggest, after looking at krb a bit, that it might be wise to
create 3.2.7 as a feature-for-feature upgrade of 3.2.5, and have a
samba_with_extra_features_3.2.7.bb package that hauls in the extra
dependencies.  But historically speaking, in most of the previous cases,
the OE gods seem to prefer the other way around.  I'm ok with that -- I
have no particular pain with changing SlugOS to depend upon (for
example) "samba-nokrb" until the krb problem gets sorted.

But I can't easily do that in this case, because the refactoring work
removed 3.2.5 altogether, so I would have to play all sorts of fun games
with git to bring back an old copy in order to name it
"samba-nokrb_3.2.5.bb" or such.

>> Anyway here is what I had been thinking about previously as you are
>> right, the changes are significant; create a separate samba-ads build
>> this weekend and revert the changes to samba. I will do this at some
>> point this weekend. Sorry if updating my packages upsets you, if you
>> don't see AD client support as a worthy feature just dont use the new
>> package at the other side of the weekend.

Oh, I see the advantages of AD client support.  I love features, good stuff.

What I hate is when I finally have some free time, and find that the
autobuilders are broken and that instead of working on the distro's
priority list items, I end up having to spend that time sorting out
completely unrelated breakage.  Pardon me for being frustrated -- free
time is a precious commodity, and we're short a few developers it seems.

>> Please dont touch the samba
>> builds - I had presumed as the maintainer of this that other people
>> wouldn't mess with it.

I do not understand this line at all.  Your changes have broken the
autobuilder - I can no longer build samba.  And the way you changed it
has taken away my ability to simply use a "PREFERRED_VERSION" to select
the old, working version in the interim.  Given this untenable
situation, why would I or anyone else not be permitted to fix it?  For
example, we had a problem with busybox the other day -- Koen stepped in
with a very nice fix that resolved the issue nicely; nobody questioned
who "owned" busybox.bb?

Mike (mwester)

Re: samba-3.2.5 missing

[Tim Ellis]

On 31 Jan 2009, at 15:53, Mike (mwester) wrote:

> Tim Ellis wrote:
>>> Calm down, thanks. I authored 3.2.5 for use in foonas which NAiL
>>> pushed for me originally, and created the 3.2.7 build with active
>>> directory support also for foonas - I tested this on multiple arches
>>> and libcs in my target distributions and they work fine. I had
>>> presumed when I started working on stuff here that I could  
>>> maintain my
>>> packages as I see fit
>
> No.  Once you add a package, it is available for others to use, and  
> you
> need to take into consideration that others may, in fact, be using it!


>>> and have ensured the older samba versions have
>>> not included this functionality
>
> What does that mean?  Are you saying that because you added 3.2.5 that
> you feel entitled to remove it, and replace it with one that adds
> significant additional dependencies?  So I should set my
> PREFERRED_VERSION back to a 3.0.x version of Samba?  That's  
> ridiculous.

>>> - and I followed the dev guidelines on
>>> the wiki and moved to the upgrade - was this wrong?
>
> Yes.  Let me expound on the problem.
>
> 3.2.5 included a specific set of features, with a specific set of
> dependencies.
>
> There are many cases where additional features should be enabled in a
> package -- and it is often the case that these additional features can
> cause trouble for other distros or users, perhaps because they have
> dependencies that may be unbuildable (as in this case), or perhaps the
> dependencies are undesirable (dbus pulling in all of the X libs was  
> such
> a case, recently), or perhaps the dependencies are just too big (opkg
> had that problem).
>
> S*** happens -- people have to move forward.  But there's no need to
> break it for an entire distro; simply leaving the original version
> pre-additional-dependencies about is sufficient to avoid it.  And  
> that's
> what's happened here -- 3.2.7 won't build because the dependencies  
> won't
> configure.  Yet neither can I go back to the old working 3.2.5 --
> because it was REMOVED!
>
> I further suggest, after looking at krb a bit, that it might be wise  
> to
> create 3.2.7 as a feature-for-feature upgrade of 3.2.5, and have a
> samba_with_extra_features_3.2.7.bb package that hauls in the extra
> dependencies.  But historically speaking, in most of the previous  
> cases,
> the OE gods seem to prefer the other way around.  I'm ok with that  
> -- I
> have no particular pain with changing SlugOS to depend upon (for
> example) "samba-nokrb" until the krb problem gets sorted.
>
> But I can't easily do that in this case, because the refactoring work
> removed 3.2.5 altogether, so I would have to play all sorts of fun  
> games
> with git to bring back an old copy in order to name it
> "samba-nokrb_3.2.5.bb" or such.
>

I read all the OE policies before starting here so as not have issues,  
including this one:

http://wiki.openembedded.net/index.php/Upgrading_Packages

If this is incorrect maybe a core dev can update it. I've been trying  
to stick to all the OE policies, and because this page is wrong this  
has now caused an issue.

Is it right that you will want every single point release of samba I  
add then? Keeping the most recent of each major version is fair  
enough, as well as any packages that are preferred by distros.  
Hoarding every single version ever is pointless and just creates extra  
cruft in OE no-one is going to use and will lead to lots of duplicate  
stuff and retained packages with security issues and bugs.

I checked before the commit and no-one preferred this version in any  
distro. I had presumed again that since no distribution in dev  
actually prefers 3.2.5 that a minor version increment with mostly just  
security and bug fixes would be moved to. Also, I can't tell if  
someone has set a PREFERRED_VERSION in their local copy.

Ultimately adding and retaining every single point release going  
forward is going to create unnecessary mess and make it more of a pain  
to maintain. Where does it end? I guess at some point it will have to.  
I will however take your comments on board and not remove insecure  
buggy point releases of the same major version in the future.

>>> Anyway here is what I had been thinking about previously as you are
>>> right, the changes are significant; create a separate samba-ads  
>>> build
>>> this weekend and revert the changes to samba. I will do this at some
>>> point this weekend. Sorry if updating my packages upsets you, if you
>>> don't see AD client support as a worthy feature just dont use the  
>>> new
>>> package at the other side of the weekend.
>
> Oh, I see the advantages of AD client support.  I love features,  
> good stuff.
>
> What I hate is when I finally have some free time, and find that the
> autobuilders are broken and that instead of working on the distro's
> priority list items, I end up having to spend that time sorting out
> completely unrelated breakage.  Pardon me for being frustrated -- free
> time is a precious commodity, and we're short a few developers it  
> seems.


>>> Please dont touch the samba
>>> builds - I had presumed as the maintainer of this that other people
>>> wouldn't mess with it.
>
> I do not understand this line at all.  Your changes have broken the
> autobuilder - I can no longer build samba.  And the way you changed it
> has taken away my ability to simply use a "PREFERRED_VERSION" to  
> select
> the old, working version in the interim.  Given this untenable
> situation, why would I or anyone else not be permitted to fix it?  For
> example, we had a problem with busybox the other day -- Koen stepped  
> in
> with a very nice fix that resolved the issue nicely; nobody questioned
> who "owned" busybox.bb?


I hope you can see from the autobuilder logs I tested my changes  
thoroughly on multiple platforms/libcs before the 3.2.7 push - I'm  
happy to try and recreate this issue if you tell me what distro you  
are working with as it works for all the distros I tried it on,  
however this is a dev branch right? Occasional breakage happens  
sometimes, despite best efforts. I hope you can see the benefit in the  
samba cleanup as it was very messy and repetitive before.

Again this stems from the guidelines in the wiki (New_Dev 3) - it  
looked pretty much like you were just going to push your changes  
without allowing time for discussion or consideration for the recent  
samba cleanup and you were clearly unsure in your irresponsible  
sounding first email "I'm going to re-create samba-3.2.5 as best as I  
can (it's way late,
maybe I'll screw it up and nobody's builds will work, who knows". I  
hope you can see I've pretty much been trying to stick with the wiki  
guidelines to try and not create issues - I expect to be given the  
same consideration or whats the point in having rules/guidelines at all?

I will probably be able to push changes discussed at some point today,  
but after I'm happy they are all working. Normally if I get a blocker  
I would try and talk to the maintainer and remove the package until  
its fixed - I suggest you do that unless you are testing samba.

Thanks,

Tim

Re: samba-3.2.5 missing

[Mike (mwester)]

Tim Ellis wrote:

> Is it right that you will want every single point release of samba I add
> then? 

You need to re-read my mail.  It is NOT about point releases, it is the
fact that you did NOT just do a point release; you added major new
dependencies and then deleted the original recipe.  It also has nothing
to do with the desirability of the new recipe -- heck it doesn't matter
if your recipe will solve global warming if it won't build.

> working with as it works for all the distros I tried it on, however this
> is a dev branch right? Occasional breakage happens sometimes, despite
> best efforts. I hope you can see the benefit in the samba cleanup as it
> was very messy and repetitive before.

I acknowleged that.  That's not the problem. And neither is a cleanup a
problem.

The problem is that you added major new dependencies in a new version
and deleted the old one.

It has nothing whatever to do with anything you're talking about -- it's
really very simple!  And don't quote OE guidelines at me either.  Please
grep for "_slugos" and other things in the recipes -- you'll find all
the places where I've taken enormous pains to ensure that the changes I
make do not risk anyone else's environment or builds.  I'm not even
asking *that much* -- I'm just asking that when someone commits a major
new recipe, that they don't delete the old one -- so that I can go
adjust my environment to build the old one until I can debug and
troubleshoot why the new one won't work.

There would be no problem at all if, in fact, your change was a minor
update - but it wasn't! You added major new dependencies in a dot
upgrade, and then deleted the original recipe.  That combination of
actions, together, is the problem.

> I will probably be able to push changes discussed at some point today,
> but after I'm happy they are all working. Normally if I get a blocker I
> would try and talk to the maintainer and remove the package until its
> fixed - I suggest you do that unless you are testing samba.

Again, I can't follow what you're saying here.  You want me to send an
email, and then wait for you to argue with me via email, and finally
commit a fix that may or may not work?  That's what we're doing, right?

But look - I've now spent more time in trying to get this all fixed, and
in discussing this than it's worth.  Really.

So just forget it completely.

I'll just commit my own samba-nokrb recipe (I recovered the old stuff
from git; it's really quite easy when one is wide awake), and we can
move on.  I'll even put it in my own package directory to avoid any
confusion.

Thanks
Mike (mwester)

Re: samba-3.2.5 missing

[Tim Ellis]

Thank you for re-clarifying this yet again, I had accepted the feature  
parity issue several emails ago and agreed to fix it as soon as I can  
test and get a proper fix up and was just seeking clarification. If  
you just can't wait for this - sure go ahead and submit another package.

Thanks for being so patient and helping to educate me on these  
undocumented policies.

Tim

On 31 Jan 2009, at 18:57, Mike (mwester) wrote:

> Tim Ellis wrote:
>
>> Is it right that you will want every single point release of samba  
>> I add
>> then?
>
> You need to re-read my mail.  It is NOT about point releases, it is  
> the
> fact that you did NOT just do a point release; you added major new
> dependencies and then deleted the original recipe.  It also has  
> nothing
> to do with the desirability of the new recipe -- heck it doesn't  
> matter
> if your recipe will solve global warming if it won't build.
>
>> working with as it works for all the distros I tried it on, however  
>> this
>> is a dev branch right? Occasional breakage happens sometimes, despite
>> best efforts. I hope you can see the benefit in the samba cleanup  
>> as it
>> was very messy and repetitive before.
>
> I acknowleged that.  That's not the problem. And neither is a  
> cleanup a
> problem.
>
> The problem is that you added major new dependencies in a new version
> and deleted the old one.
>
> It has nothing whatever to do with anything you're talking about --  
> it's
> really very simple!  And don't quote OE guidelines at me either.   
> Please
> grep for "_slugos" and other things in the recipes -- you'll find all
> the places where I've taken enormous pains to ensure that the  
> changes I
> make do not risk anyone else's environment or builds.  I'm not even
> asking *that much* -- I'm just asking that when someone commits a  
> major
> new recipe, that they don't delete the old one -- so that I can go
> adjust my environment to build the old one until I can debug and
> troubleshoot why the new one won't work.
>
> There would be no problem at all if, in fact, your change was a minor
> update - but it wasn't! You added major new dependencies in a dot
> upgrade, and then deleted the original recipe.  That combination of
> actions, together, is the problem.
>
>> I will probably be able to push changes discussed at some point  
>> today,
>> but after I'm happy they are all working. Normally if I get a  
>> blocker I
>> would try and talk to the maintainer and remove the package until its
>> fixed - I suggest you do that unless you are testing samba.
>
> Again, I can't follow what you're saying here.  You want me to send an
> email, and then wait for you to argue with me via email, and finally
> commit a fix that may or may not work?  That's what we're doing,  
> right?
>
> But look - I've now spent more time in trying to get this all fixed,  
> and
> in discussing this than it's worth.  Really.
>
> So just forget it completely.
>
> I'll just commit my own samba-nokrb recipe (I recovered the old stuff
> from git; it's really quite easy when one is wide awake), and we can
> move on.  I'll even put it in my own package directory to avoid any
> confusion.
>
> Thanks
> Mike (mwester)
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

samba-3.2.5 missing

[Mike (mwester)]

Looks like the recipe for samba-3.2.5 is missing.

It got renamed very recently to samba-3.2.7 -- which is a bit of a sore
point to begin with, as some people may have set a PREFERRED_VERSION
which would now break.

But it's much much worse -- the new samba-3.2.7 doesn't just update
3.2.5, it enables krb and ads support.  Marvelous, I'm sure -- but what
if I don't have space for all those libraries and all?

Not to mention that krb won't build, so now samba won't build either.

I'm going to re-create samba-3.2.5 as best as I can (it's way late,
maybe I'll screw it up and nobody's builds will work, who knows?), and
set the default preference for 3.2.7 to -1.  That really should have the
krb stuff backed out, and a "samba-krb_3.2.7" recipe created, IMO.

regards,
Mike (mwester)

Re: samba-3.2.5 missing

[Mike (mwester)]

Mike (mwester) wrote:

> I'm going to re-create samba-3.2.5 as best as I can (it's way late,
> maybe I'll screw it up and nobody's builds will work, who knows?),

Screw it.  The changes are ******HUGE*****.   Can whoever removed the
working 3.2.5 please put it back?  Thank you.

Regards,
Mike (mwester)