Patches & Modules - Questions and your Opinion?

Jean-Michel Brünn jean.bruenn at ip-minds.de
Mon Mar 17 19:28:22 CET 2008


Hello,

On Mon, 17 Mar 2008 10:10:44 -0700
"Kok, Auke" <sofar at foo-projects.org> wrote:

> Jean-Michel Brünn wrote:
> > Hello,
> > 
> > i have short questions about patches and modules in moonbase. If i remember
> > correct we want patches for modules only if they're needed. So my questions:
> > 
> > 1. Who defines wether a patch is needed?
> 
> you

Thats not true, if you read the rest of your answers. The half of it maybe true. Because if i think a patch is needed, others would complain: It's running without it. So it's not up to me, nor up to a user.

There are two things:
	1. Adding patches because they are useful and
	2. Adding patches because they COULD be useful.

First means, if something is broken and a patch exists, we need that patch.
Second means, we don't know what the lunar users are doing nor what they want. Not all of that users are in IRC, on the Maillinglists or writing Bug reports in form "xyz not working, but there's a patch for it". So we have to think about: Could it be, that user xyz, could need that. And thats something we aren't doing.

hopefully i'm not confusing with that sentences.

> 
> > 2. How about patches like branch updates from official side, fixing bugs,
> > possibly not critical bugs.
> 
> if we need those patches because something breaks then we should add them. if
> nothing breaks then we don't care.
> 

And here's where it's no longer up to me. Because it's ONLY up to me, if something isn't working and i need it. Also other people needs to need that, too, otherwise no developer would commit such a patch.

> > 3. How about patches giving optionally more security or adding features?
> 
> that's really a fuzzy term ("more security") and I don't see that we should waste
> much time on that. there is not really a lot of demand in the lunar community for
> "super secure" linux. most of the time because it is secure already and the extra
> secureness is just a patch for people who don't "think" secure but just want to
> "feel" more secure.

Thats why i gave the example with glibc. "Demand" is by the way an interesting word if we think about it: Nobody will demand anything if it's not there. Demand exists as long as you give it. For example:

	if we provide two versions of lunar, one with patches improving the security, 
	and one without them, both aren't breaking something. What would the user 
	choose?

You're arguing such patches are for users who don't think about security. I think you're looking at it from a wrong point. Look at it this way:

	Such patches would not higher the security for people not thinking about 	
	security.
	INDEED such patches would higher and improve the security of people 
	thinking about security.

know what i mean? It's not "giving the user a feeling of security" it's "improving the security or security features for users interested in security".

> 
> > Could be that you want examples.. so here are some:
> > 
> > Bash fixes 1. http://ftp.gnu.org/gnu/bash/bash-3.2-patches/
> 
> nothing is broken really, lunar works OK - so this is really not needed IMHO

see my explaination at the top of this mail. It's not needed, because nobody said something. Was there ANYONE looking what the patches are doing?

001 is fixing a bug
002 is fixing a bug where "make install" could fail
005 is fixing a bug, where you could get incorrect results
010 is fixing a bug with glibc
015 is fixing a bug that can cause the shell to hang and litters the filesystem

No one reported any problems. Does that mean, that the above problems aren't there? No. They are there. Thats why there are patches for it.

> > Glibc (hardening) 2.http://www.linuxfromscratch.org/patches/hlfs/svn/glibc-2.5.1-arc4_prng-2.patch
> 
> our glibc is at 2.7... is this really not an old patch?

okay. I should have used a newer one, anyway i used that as an example, to show the direction in which i would go by using "patches to improve the security". What the patch does - is the interesting thing. and it's just an example. Not a suggestion for a patch we should use now.

> 
> > I know that everything is running without that patches, but wouldn't it be
> > better and giving more security to add such patches? We could add those patches
> > "if available" so we won't wait for a patch before we switch a module to a
> > newer version. Anyway, i know that would perhaps mean more testing.
> 
> that's OK - like I said it is really up to the developer. If you think it's worth
> for everyone to recompile an app because of something AND you think it's worth for
> others to do so as well because it will improve their experience then it's a safe
> bet and go for it.

So, as we both know, it doesn't make sense to add such patches, nor would be users recompile there apps because there are some patches available (would you? i would. But most users want a running system, not a every-day-recompile-system). At least such patches are only interesting for modules we aren't updating in a short time. For example: Bash, Gcc, Glibc, Binutils. (That are critical apps, but we update them not very often. Other not-critical-apps we don't update often are interesting for such patches, too)

> 
> if that's not the case then you should obviously reconsider.

It seems that i'm having again an uncommon opinion. So it wouldn't make sense if i do further thinking over this, or? I really really like Lunar. Thats why i'm using it. Developers are doing a great job by keeping Xorg up to date. Doing a great job on big things like kde4. Doing a great job by optimizing the lunar tools like lnet and other stuff. And they're doing much more.

But in my opinion, we, or the lunar developers, are looking at it in a wrong way. You're fixing existing problems. But there are still "unknown" problems we'll never hear about. Such problems could be fixed with the official bugfixes.

A user putting in the lunar cd, booting from it. installing xyz. doing abc with the result it's not working - Will most likely use another distribution, if he knows that it's working there. There is a chance 50/50 that the user will a) ask on IRC or the ML b) will write a bugreport.

And please. I know that lunar isn't a distribution for beginners.


> Cheers,
> 
> Auke
> 
> 
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar-dev


-- 
Jean-Michel Brünn <jean.bruenn at ip-minds.de>


More information about the Lunar-dev mailing list