Stephan Bergmann wrote:
Hi all,
Just a reminder that the next chat is scheduled for Friday, December 7,
2007, 10:00--11:00 UTC on irc://freenode/ooopackaging.
And the transcript:
[2007-12-07 11:00:23] <sb_> Hi Folks. (Not too many there?)
[2007-12-07 11:01:16] <sb_> Anyway, we can do a status round (for the
transcript records...). I can begin:
[2007-12-07 11:01:44] -->| kendy_ ([EMAIL PROTECTED]/suse/x-a0ba8da4481b7d37)
has joined #ooopackaging
[2007-12-07 11:01:54] <kendy_> Hello!
[2007-12-07 11:02:04] <sb_> Currently working on the brand layer. An
Office product will (at least conceptually) be in three layers:
[2007-12-07 11:02:18] <sb_> - URE, serving as both standalone product
and as lowest layer.
[2007-12-07 11:02:38] <sb_> - Basis (I call it for now), serving as the
common, shared parts of OOo (the biggest layer).
[2007-12-07 11:02:54] <sb_> - Various Brand layers (plain OOo, BrOffice,
StarOffice, etc.)
[2007-12-07 11:04:11] -->| pmladek
([EMAIL PROTECTED]/suse/x-231dea7b69417720) has joined #ooopackaging
[2007-12-07 11:04:17] <sb_> I have a rudimentary version running on
Unix, with an OOo and a StarOffice Brand layer each. Most work is now
to move exactly what is necessary from the basis to the brand layer so
that those new products are faithful copies (functionality-wise) of the
existing, monolithic ones.
[2007-12-07 11:04:35] <sb_> That's it from my side. Next please.
[2007-12-07 11:04:54] <is> I can explain native110
[2007-12-07 11:05:07] <is> This cws is currently Ready for QA
[2007-12-07 11:05:26] <is> It contains changes regarding the language
specific files.
[2007-12-07 11:05:47] <is> All language specific files are forced into
language specific packages.
[2007-12-07 11:06:13] -->| kr_ ([EMAIL PROTECTED]) has
joined #ooopackaging
[2007-12-07 11:06:22] <is> scp tooling checks, that this assignments in
scp were done correctly.
[2007-12-07 11:06:55] <is> Additionally templates were introduced, that
all modules, that will become language dependent packages
[2007-12-07 11:07:18] <is> are automatically crated for all available
languages in scp2.
[2007-12-07 11:07:47] <is> In native121 I currently investigate a new
core package structure
[2007-12-07 11:08:14] <is> and the possibility to share products, like
URE on Windows.
[2007-12-07 11:08:26] <is> That's it. Next please.
[2007-12-07 11:09:34] <pmladek> Hello. Shortly about me. I maintain the
OOo packages for Novell.
[2007-12-07 11:10:04] <pmladek> I wasn't able to join the latest meeting
but read the log. I was pleased by the results, ...
[2007-12-07 11:11:08] <pmladek> My objectives are to allow building
various peices of OOo separately, using the devel package. For example,
writer, ...
[2007-12-07 11:11:31] <pmladek> I also wants to build some packages as
noarch.
[2007-12-07 11:12:28] <pmladek> I have prepared a bit hacky solution to
build the language stuff separately and noarch several months ago.
[2007-12-07 11:12:57] <pmladek> Unfortunately, I have been busy, so I
didn't move forward last weeks.
[2007-12-07 11:13:07] <kr_> Ladek, may you enlighten me what noarch
packages would contain? All architecture independent files?
[2007-12-07 11:13:34] <pmladek> I am afraid that I will not have time
until the end of the year :-(
[2007-12-07 11:14:34] <pmladek> Noarch packages should inclide the files
that are the same on all archtectures.
[2007-12-07 11:15:12] <kr_> thanks (stupid question :-)
[2007-12-07 11:15:18] <pmladek> I am not talking about operating systems
like Linux or Windows but about architectures like i586, x86_64, ppc, ...
[2007-12-07 11:16:19] <pmladek> That's it. Next please.
[2007-12-07 11:16:28] <sb_> ...but we should be able to extend that to
multiple OSs, right?
[2007-12-07 11:16:47] <pmladek> Yes, that would be great.
[2007-12-07 11:17:05] <pmladek> I'll take it in mind.
[2007-12-07 11:17:25] <sb_> great
[2007-12-07 11:17:43] <kr_> I am currently preparing a brief paper
regarding packaging (
http://wiki.services.openoffice.org/wiki/User:Kr/Packaging )
[2007-12-07 11:18:30] <kr_> in my understanding (please correct me if I
am wrong), we have files / packages which dependent on various
dimensions / achses
[2007-12-07 11:18:57] <kr_> the dimensions I see are: OS, ARCH, BRAND,
LOCALE, VERSION ... anything missing?
[2007-12-07 11:19:58] <kr_> everything to be installed has one or
multiple value(s) on this vector
[2007-12-07 11:21:15] <kr_> e.g. there may be files depending on the
locale and the brand but nothing else, the vector would look like (0, 0,
1, 1, 0) in principle
[2007-12-07 11:22:15] <kr_> or (0, 0, "OOo", "english", 0) for OOo
English respectively (0, 0, "SO", "english", 0) for StarOffice English
[2007-12-07 11:23:28] <kr_> does somebody get what I mean? Or am I just
confusing ;-) ?
[2007-12-07 11:25:26] <pmladek> kr_: The page is interesting.
[2007-12-07 11:26:19] <pmladek> kr_: The approach with the vector might
help to describe the problems. I am not sure when we could end with it.
It looks good to me.
[2007-12-07 11:27:43] <kr_> pmladek: The approach basically is, to to
"package" everything once only, in a granularity suitable to create all
our products, following a kind of "shopping card approach" ...
[2007-12-07 11:28:43] <kr_> I mean, you take writer_linux_x86 +
writer_OOo + writer_en, put it together on a CD and have an OOo writer
only product
[2007-12-07 11:29:05] <pmladek> kr_: The only problem I see is that
various OSs have different types of packages.
[2007-12-07 11:29:24] <pmladek> kr_: Linux has RPMs, Debs. Windows has
MSI...
[2007-12-07 11:29:55] <pmladek> kr_: We should somewhat bundle the
things into these native packages.
[2007-12-07 11:30:03] <sb_> These are conceptional, abstract packages only.
[2007-12-07 11:30:32] <sb_> A later step in the build pipeline creates
concrete, platform-dependent packages from abstract ones.
[2007-12-07 11:31:04] <kr_> pmladek: I plan to take a deeper look at the
various installation approaches, currently looking into Windows, so see
how (and if) we could achieve product construction and what the
constraints are
[2007-12-07 11:31:05] <pmladek> sb_: Sounds great then. Thanks for
exlanation.
[2007-12-07 11:31:45] <sb_> Idea is to do that as late as possible
(e.g., ship a CD with abstract packages only, and tooling to translate
those to either RPMs or MSI, depending on who is using the CD). But
those are dreams right now.
[2007-12-07 11:32:37] <kr_> That would be something as "late binding"
for packages -> "late packaging" :-)
[2007-12-07 11:33:08] <pmladek> I see how it could help you!
[2007-12-07 11:34:05] <kr_> I think an intermediate approach would be,
deliver RPMs, DEBs, MSM etc. and to create the various products out of
these, would allow to reuse on this level
[2007-12-07 11:34:49] <pmladek> kr_: Sounds reasonable.
[2007-12-07 11:36:02] <kr_> Weakest point for me currently is Mac, as I
only have a very shallow understanding of what is possible or not (e.g.
sharing files, how updates work etc)
[2007-12-07 11:37:09] <kr_> For Windows the WiX stuff
(http://sourceforge.net/projects/wix/) provides a simple way to learn
about Windows Installation services ...
[2007-12-07 11:40:50] <kendy_> kr_: These abstract packages, you mean
something like what EPM is supposed to do + enhanced for Win?
[2007-12-07 11:41:03] <kendy_> kr_: Then I am not sure if I like the
idea ;-)
[2007-12-07 11:41:54] <kendy_> kr_: What works best for us (as a linux
distributor) is the possibility to have our own spec files
[2007-12-07 11:42:12] <kendy_> kr_: Meaning that we are able to install
the product to a lining system
[2007-12-07 11:42:33] <kendy_> kr_: and separate from it we have a list
of files what belongs to which package.
[2007-12-07 11:42:54] <kendy_> kr_: But maybe I just misunderstood you
[2007-12-07 11:43:06] <kr_> kendy_: what would you write into the spec
files that is not generatable ?
[2007-12-07 11:43:08] <kendy_> kr_: And by the abstract packages you
mean just these lists :-)
[2007-12-07 11:43:43] <kendy_> kr_: Spec files describe the entire build
process.
[2007-12-07 11:43:51] <pmladek> kr_: In the spec file we need to build
the package the way: configure, make, make install
[2007-12-07 11:43:55] <kr_> kendy_: The "lists" could be the abstract
packages, though likely we need some more info ...
[2007-12-07 11:44:11] <pmladek> kr_: And generate the list of files for
each subpackage during the install phase.
[2007-12-07 11:44:33] <is> Sorry, have to leave now.
[2007-12-07 11:44:37] <--| is has left #ooopackaging ("Leaving")
[2007-12-07 11:45:12] <sb_> Sounds like the spec file approach would
clash with the current, platform independent build mechanism.
[2007-12-07 11:45:32] <kendy_> sb_: I'm afraid a bit of that, yes :-(
[2007-12-07 11:45:43] <kr_> we may can generate the spec files out of
the "abstract packages", to be more compliant with the distributors
[2007-12-07 11:45:45] <kendy_> sb_: Currently we do not use the EPM at all
[2007-12-07 11:45:58] <sb_> I have no idea what EPM is.
[2007-12-07 11:46:25] <kendy_> sb_: That's the app that generates OOo's
rpms & debs
[2007-12-07 11:46:37] <sb_> Ah, I see.
[2007-12-07 11:46:38] <obr> EPM is a kind of meta packager
[2007-12-07 11:46:44] <kr_> Is it the ESP Package Manager?
[2007-12-07 11:46:48] <obr> yes
[2007-12-07 11:46:50] <kendy_> Exactly
[2007-12-07 11:47:14] <pmladek> sb_: How would the two approaches clash?
[2007-12-07 11:47:57] <pmladek> sb_: I think that we should keep the
simplay approach: configure, make, make install for developers anyway, ...
[2007-12-07 11:48:26] * kendy_ supports pmladek in that :-)
[2007-12-07 11:48:53] <sb_> The notion of "spec files" is too vague for
me at the moment to say exactly how things would clash. (Hopefully they
won't at all. Mostly gut feelings.)
[2007-12-07 11:49:03] <kr_> We can do that anyway, though that likely
means some more work to do ;-)
[2007-12-07 11:49:29] <sb_> Anyway, whatever we introduce, we should
make it abstract enough so that all concrete platforms can happily live
under it (without too much bending for any single platform).
[2007-12-07 11:50:02] <kr_> If I understand correctly, what the Linux
distros would like to see is something as "configure / make / make
install" followed by a packaging phase, right?
[2007-12-07 11:50:21] <kendy_> kr_: If there's possibility to do it so
that there's 'make install', which will install OOo and additionally
create the lists what would belong where (the abstract packge
description?), it would be OK for us I think.
[2007-12-07 11:50:56] <kendy_> kr_: Yes, configure/make/make install is
really essential for us.
[2007-12-07 11:51:24] <kr_> kendy_: I don't see any principle problems
with that ... all information is there ... just needs to be kept and
provided - anybody else seeing principle problems?
[2007-12-07 11:51:28] <pmladek> kr_: The spec file normaly describes the
whole process how to get RPMs.
[2007-12-07 11:52:02] <sb_> pmladek: That's probably the weak spot.
[2007-12-07 11:52:18] <pmladek> kr_: How to extract sources, apply
patches, build the binaries, install the binaries, and what file belongs
to what subpackage.
[2007-12-07 11:52:37] <kr_> pmladek: AFAIK, RPM takes a list of files
and creates concrete .RPMs out of already installed files ... ?
[2007-12-07 11:52:52] <pmladek> kr_: Yes
[2007-12-07 11:53:07] <pmladek> sb_: I do not think that it should be a
problem
[2007-12-07 11:53:31] <kendy_> kr_: Yes, but the 'installed files' are
installed according to what is in the spec file.
[2007-12-07 11:53:49] <sb_> Maybe it would help to see a (preliminary)
CWS/whatever to get a more concrete idea of what you plan to change how.
[2007-12-07 11:53:59] <kendy_> kr_: So it's not that you'd do
./configure ; make ; make install ; let-rpm-create-the-rpms, but
[2007-12-07 11:54:28] <kendy_> kr_: you call let-rpm-create-the-rpms,
which calls ./configure ; make ; make install by itself
[2007-12-07 11:54:50] <kr_> kendy_: so RPM is the frontend ?
[2007-12-07 11:55:03] <pmladek> sb_, kr_: It might look complicated but
it is simple in fact.
[2007-12-07 11:55:38] <sb_> pmladek: The question is whether it fits
into the more-or-less platform independent framework (that we *need*).
[2007-12-07 11:55:44] <pmladek> sb_, kr_: we only need the possibility
to easily install the files on the system and create the list of files
for each subpackage during it.
[2007-12-07 11:55:49] <kendy_> kr_: Not sure how you mean it?
[2007-12-07 11:56:17] <kendy_> [the 'let-rpm-create-the-rpms' is in fact
somtehing like 'rpm -b the_spec_file.spec']
[2007-12-07 11:57:54] <kr_> kendy_: Until now I only created RPMs by
using the pure packaging feature ... but AFAIK it can trigger the build
itself before doing the packaging .. that means it is a "frontend" to
the build process ...
[2007-12-07 12:00:19] <pmladek> kr_: You described it perfectly. rpm can
be used as a frontend for the build process.
[2007-12-07 12:00:35] <pmladek> kr_: It could describe it by a shell
script, ...
[2007-12-07 12:01:43] <kr_> I am confident, that we can find a way, to
make our build "RPM" compliant ... at least to a reasonable state
[2007-12-07 12:02:28] <pmladek> kr_: Thank you.
[2007-12-07 12:02:40] <kr_> Is it OK to regard this as a "soft"
requirement ?
[2007-12-07 12:04:21] <kr_> I mean, you somehow survived with what we
currently have until now ;-)
[2007-12-07 12:04:30] <sb_> Can we close for today?
[2007-12-07 12:04:46] <kendy_> kr_: Yes, because we patched the build so
that it can do the 'make install'
[2007-12-07 12:04:47] <kendy_> :-)
[2007-12-07 12:05:08] <kr_> kendy_: I see :-)
[2007-12-07 12:05:12] <kendy_> kr_: So it's kind of hard requieremnt for
us if we don't want to have our own specific changes ;-)
[2007-12-07 12:05:45] <kr_> Understood, I am going to investigate
further, to see what it actually takes
[2007-12-07 12:05:46] <kendy_> Which is always better to avoid ;-)
[2007-12-07 12:06:07] <kendy_> kr_: I'll post you how we do the 'make
install' in a sec.
[2007-12-07 12:06:38] <kendy_> kr_:
http://svn.gnome.org/viewvc/ooo-build/trunk/bin/ooinstall
[2007-12-07 12:07:35] <kendy_> So - I think we can close. Thank you all!
[2007-12-07 12:07:50] <kr_> going to take a look ... and bye :-)
[2007-12-07 12:07:56] <kendy_> Bye!
[2007-12-07 12:08:05] <sb_> OK, since next year, then. Bye.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
