Re: [Linuxcoe-devel] Update on packaging

[Louis B. <lou...@hp...>]

Hi guys,

I don't know why we're going through another iteration of the naming
convention used.  We should discuss it at today's core meeting but my
(rough) feeling is that LinuxCOE needs something else than just another
naming convention.

-sd- is not much more (or less) cryptic than sysdes so it won't change
much at the end. But it do means that it will ask for (yet another)
rework of the .spec files, something for which I have absolutely no time
for.

I'm not against discussion, but sometimes the buck needs to stop
somewhere. I thought we had this discussion before. It's been close to a
year and we still don't have RPM/DEB packages yet.

So here is how I will do it : I'm taking friday off to nail down a set
of RPM, named as they are today in the CVS. Hopefully we'll be able to
have the ./images directory out of the way in order to have the overlays
RPM a bit lighter.

Then we'll need to get the RPM out in the public so they can be tested.

Sorry if I'm sounding a bit rude, but with the (very) limited resources
that I have it is the only thing I can offer.

Regards,

..Louis

Le mardi 16 octobre 2007 =C3=A0 23:55 +0000, Cornec, Bruno (Linux Consultan=
t)
a =C3=A9crit :
> Bryan Gartner said on Tue, Oct 16, 2007 at 01:02:47PM -0600:
>=20
> > > linuxcoe-sd-base and linuxcoe-sd-docs (I now use this one) or
> > > linuxcoe-sysdes and linuxcoe-sysdes-docs
> >
> > I can go either way with this, except "sd" is rather short and non-desc=
ript,
> > so I'd like to propose
> >
> >       linuxcoe-sysdes-common
> >               (vs. -base, as that is more common, at least in .deb spac=
e)
>=20
> *I* think that common is used when the brick is used by other potential
> upper layer (e.g. vim-common with vim-extended & vim-X11) whereas base
> is used when the component is the basis of the rest of the stack.
>=20
> So IMVHO in that case base is fine.
> But it's just for the pleasure to discuss with you, I'll let the long
> time writer decide, and adopt it.
> What I'd need is a parid concensus ;-)
>=20
> >       linuxcoe-sysdes-docs
>=20
> I take it ;-)
>=20
> (Too bad CVS doesn't support mv)
>=20
> > Another proposal is to modify the distro overlays as:
> >
> >       linuxcoe-sysdes-vend-<Distro>
> >               (instead of the "data*all" approach)
>=20
> Is vend more clear for native english speakers ?
> (For non native english speaker such as myself, I find data quite
> explicit). But again, let you choose.
>=20
> > > I'll then derived as we need the same choice vor /var/log and /var/li=
b
> > > (What I won't do the make another subdir below with the verion name a=
s
> > > fr packages this is useless because you can't have multiple instances=
)
> >
> > Actually you can easily have multiple instances (and this is quite
> > useful right now since we are making the 4-4.1 transistion).  We do
>=20
> Well this may on a test platform. But on a platform managed by packages,
> when you upgrade, what you eally want is that the new application takes
> place of the old one.
>=20
> When I do urpmi postfix / apt-get install postfix, I just want the new
> version. Then it's up to the packagers to be clever enough to keep the
> configuration files safe, or ven to aply filter to them if format has
> changed.
>=20
> The only case, where it would be acceptable IMO, is when you want
> multiple major versions in parallel (apache1 and apache2) However, this
> is generally for a short period of time, in particular when they all
> listen on the same port :-(
>=20
>=20
> Also I want to look for log files under /var/log/linuxcoe-sysdes, not
> under /var/log/linuxcoe-sysdes/4.1, and then realize it's the new
> version so should look at 4.2, ...
> More confusing than useful for me.
>=20
> And also a system like rpm won't let you have 2 packages with the same
> name and 2 versions different coexist on the system ;-) Rightly IMO .
>=20
> > it all the time as we move into production.  And this is almost trivial
> > with the next change that was implemented:
>=20
> I understand that for tar files, potentially but for packages I find it
> less useful.
>=20
> Bruno.
> --
> Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA=
 IET
> http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco=
.net
> Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/l=
inux
> La musique ancienne?  http://www.musique-ancienne.org http://www.medieval=
.org
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
--=20
Louis Bouchard, Linux Support Engineer
EMEA Linux Competency Center,
Linux Ambassador, HP

HP Services                       1 Ave du Canada
HP France                         Z.A. de Courtaboeuf
lou...@hp...             91 947 Les Ulis
http://www.hp.com/go/linux        France
http://www.hp.com/fr