google-code-export / lusca-cache

Automatically exported from code.google.com/p/lusca-cache
0 stars 0 forks source link

lusca / squid name changes #70

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Hi Guys,

while working on getting debian managed package working for my environment
I've been repeatedly frustrated with the squid name throught config files etc.

I realise that we consider lusca to be a replacement for squid - but what
is everyone's view - do I work towards name migrations to reflect
"lusca-cache" in relevant locations or am I flogging a dead horse here?

Input appreciated.

Original issue reported on code.google.com by regar...@gmail.com on 7 Oct 2009 at 2:55

GoogleCodeExporter commented 9 years ago
Yo,

So are you asking why I haven't gone through and changed a lot of the "squid" 
mentions to Lusca?

Its because I'm trying to minimise the runtime configuration and packaging 
differences to Squid-2.

What are you changing to "lusca-cache" in particular?

Original comment by adrian.c...@gmail.com on 7 Oct 2009 at 3:02

GoogleCodeExporter commented 9 years ago
Thanx for the feedback Adrian. 

It was more of a question regarding the longterm plans around lusca, if 
branding is
heading towards lusca in the future then I wanted to start assisting with the
conversions.

For now I'll then keep to the squid naming and just tweak the versioning.

Original comment by regar...@gmail.com on 7 Oct 2009 at 3:24

GoogleCodeExporter commented 9 years ago
Hi Adrian,

Sorry to dredge this one up again - while you and I obviously both use lusca as 
a
replacement to squid - I'd like to assist (if this is what you wish) to over 
time get
the name changes to lusca for binaries and headers etc.

I understand the want for minimal runtime differences, but by not doing this 
we're
making the inclusion of lusca-cache as a package (in distributions) somewhat 
more
complicated. 

It's easy enough to add all the debian bits - I use it like that daily - it's 
just
that if we want to really get this into wider use the package name will have to 
be
implemented.

What's your thoughts on this?

Original comment by regar...@gmail.com on 2 Jan 2010 at 10:25

GoogleCodeExporter commented 9 years ago
I'm of two minds about this. I'd prefer that for now Lusca is just a drop in 
replacement for Squid as much as 
possible, rather than a separate bit of software which may end up coexisting.

So I'm not really sure what to do in this instance. Why is it a problem that 
the package is "lusca" but it still installs 
to all of the Squid directory locations (except for say, /usr/share/doc/) ?

Original comment by adrian.c...@gmail.com on 19 Jan 2010 at 9:02

GoogleCodeExporter commented 9 years ago
I'm guessing Linux Standards Base may have a fit ;-) -- lemme read on what the 
ideal
is vs what makes sense to us ;-) I'll revert after that.

Original comment by regar...@gmail.com on 27 Jan 2010 at 11:54

GoogleCodeExporter commented 9 years ago
Howdy!

I'm planning on leaving the lusca package with the squid related config, share, 
etc
paths for now. I really do want to make this as much as a drop in replacement 
as can
be allowed (so both upgrades and downgrades are seamless.)

Do you think Debian/Ubuntu would be cool with that? Or do I have to maintain my 
own
binary package?

Original comment by adrian.c...@gmail.com on 27 Mar 2010 at 10:17