On Tue, 4 Jun 2002, Jeff Johnson wrote:
> > > archictecures, and data base, rather than having to manually
> > > go through, and hold in one's attention, the details of
> > > inconsistently packaged text .spec files. Much more
> > > consistent management of an entire distribution package is a
> > > direct result -- moving into a wholly new architecture whould
> > > be facilitated..
> >
> > Sorry but instead quering src.rpm for extract some informations stored in
> > spec file I can simple extract spec file and make query using --specfile.
> >
>
> Yup. What you can't get from the spec file, however, is the macros
> necessary to use the spec file. The only legacy compatible way I can
> figger to deliver the macros with the spec file is to add the macros
> used during a build to a tag in the src rpm, copy the macros from
> the src.rpm tag to
> %{_sourcedir}/%{name}.macros
> when installing a src.rpm, and add the above macro file at the beginning
> of the list of macrofiles that's read.
>
> FWIW, XML already has URL's and such to retrieve other info associated
> with a document like a spec file.
>
> > > Interoperability is increased, and the ability to identify
> > > common elements increases.
> >
> > Potential interoperability. Ask is it usefiull interoperability ?
> >
>
> Depends on what you're interoperating, a tri-cycle or a motorcycle. :-)
>
> Yes, if all you need/want to do is build a package, the current paradigm
> is OK. What I'm seeing, however, with the Red hat distro is that the other
> information associated with a package build needs to be encapsulated
> as well, and needs to be exchanged in a orderly and formal manner.
>
> Another example is your suggestion of --with-foo/--without-foo on the
> rpm CLI. Great idea, but writing a spec file with a lot of conditionals
> does some moderate damage to the concept of "reproducible builds", as
> one needs to understand more than
> rpm --rebuild foo*.src.rpm
> in order to rebuild a package if the original build included any macro
> passed from the CLI.
No no ..
All must be repeatable in well defined enviroment. If few additional
varialbles will multiply possible results all must be repeatable in each
variables combinations not each variables must produce repeatable result :)
Using some condiotional building can be necessary if someone will want
produce packages with diffrent set possibiblities than default. Obserwing
PLD developers and some adminstrators I see it is *realy* neccessary
thing. Yes addittinal combinations aren't used offen but is *used*.
Personaly I'm not using conditional build because all what is neccessary
for me is the same what is avalaible in defautl distro binaries form.
Using bcond allow ather people produce additional packages forms without
disturbing default results and simple and allow also share well tested
build procedures without reinventing wheel. Also I don't care is
additional combinations produced packages because this not my business.
In all avalaible cases (observed in RH, PLD and other distros) produced
binariees uses some default set variables settings.
Additionaly I see conditional build have some usefull consequences on
produce debug packages like build package with enable anything warning on
build stage (from autoconf by kompilers warnings to warnings produced by
any other tools used on %build, %install stage) also by use -g -O0 in
compiler options and do not stripping binaries in produced package.
If conditional builin kerb5 support it will touch well defined packages
group above will touch *any* package (except part noarch pacjages ;).
In both cases you can define for example *separated* testing procedures.
Where in this cases XMLizing can help ?
> FWIW, XML already has concepts of validation that can detect when
> there are missing elements necessary to rebuild a package reproducibly.
Get a real example. Get package with conditionaly buidin or not kerb5
support. What is importand ? for me test is in produced results is
avalaible kerb5 support or not. How it can be testet ? for exmle by
checking is produced binaries depend on kerb5 libraries or no. Where you
want use XML validation for this ? Hmm .. he .. yyy .. nowhere (?) :-)
How it can be performed now ? by adding additional stripts set for %test
sectin or by add in each now avalaible %<section>_test stage, or even by
inject this tests in %___install_post.
Maybe it is not so realistics case but will probably show on what few
persons in PLD are thinking ;)
Better examle will be probably postgresql where you can perform some tests
is produced binariews will handle correctly or not example database :)
All before touching/installing produced automatically or manualy packages.
> > > I was thinking about Ed Bailey's
> > > 'scriptlets', and my aversion to them because of the lack of
> > > commonality there. The effort of having a .spec to XML parser
> > > then supports the ability to identify common 'scriptlets'.
> >
> > IMHO if lack is other place.
> > You are try think about XMLizing from pont of view rpm package developer
> > point of view. Try think from point of view packages developers side.
> > This people lik me will ask "what usefull it can bring me on package
> > development stage ?".
>
> I suspect -- becuase all PLD spec files are already in CVS -- that
> you're missing the point that there's a great deal of common code
> embedded in spec file scriptlets that often requires a lot of
> package churn and burn to fix. Yes, macros deal with aspects of this
> problem, but, since macros are not distributed with the src.rpm, this
> can lead to breakge as described above.
This very similar to programs source code. Distributing source code isn't
neccessary distribuing also used external libraries (it also why I pont
few times for final seaparations rpm and popt library :).
This similarities was fundamentatl on understanding why it was injected to
repo and why all other build enviroments are on each developer or
automation in PLD strictly adjusted to CVS and also why CVS structutre
some modules is adjusted to some current rpm feactures.
It makes some new possibiliyties which isn't or can be but hardly
avalaible without this. And *without* touching rpm in spe.
As same like libraries macros enviroment which goes with rpm makes some
*well known enviroment*. Unrolling this eniroment inside each package if
we have some well defined enviroment isn't neccessary and/or is redundant.
Also this kind unrolling probably can be problematic on changes which may
touch on one or few packages but bigger populations or even all packages
in distributions sets.
> > > THAT allows making the scriptlets general in method and
> > > applicability, and folding pre- and -post into the %_macro-ing
> > > model, so tht other packagers (and packaging tools) can pull a
> > > well formed tool, rather than re-inventing the
> > > scriptlet-wheel.
> > >
> > > ================
> > >
> > > The ability to move rpm into state machine form should have
> > > the effect of making the code less crufty, more maintainable,
> > > and less fragile -- that is a clear win as well.
> >
> > Show me some *real* example.
>
> Trying to, I'll get there yet :-)
OK I can wait.
But still I can say all neccessaty experiments on new
feactures or demonstrations some new possibilities can be performed even
now without touching rpm core by using XSLT and rendering spec files on
backend side.
Jeff undestand me :)
I know XMLizing looks atractiv and for me in this case looks like
kind of atraction. For keep cool head it will be in this kind cases take
deep breath or drink glass of watter before make some decissions ;)
For me XMLizing do not changes anything for allow bring to new level
prouced packages quality. Why ? because it packs the same technics in
only new form.
Also do not brings anything valueable on packages developmet stage.
Yes it may bring something new/easier for rpm package developers :)
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@xxxxxxxxxxxxxxxxxx*
|
