Re: Possible framework for `debmake replacement'
Hi,
[I hope this is not a fiat, and we can still discuss this]
>>"Bruce" == Bruce Perens <bruce@pixar.com> writes:
Bruce> I too am dubious about the "compiler" form of deb-make
Bruce> replacement. The problem is that it does not catch up as policy
Bruce> changes. It would be very difficult to make a "compiler" form
Bruce> of rules builder that would automaticaly incorporate policy
Bruce> changes into existing packages as deb-make often does. Once you
Bruce> edit the generated script, you don't want to send it back
Bruce> through the tool again and lose your changes.
The sticking point everyone is hung up upon is that they don't
want the developer to loose changes when the packaging tool is rerun
(to pick up updates to pilicy, say). That is understandable, and
needs to be a firm requirement. Any implementation of the packaging
tool shall have to guarantee that. OK?
If there are technical reasons against a compiler tool, I want
to hear them, but unfeasibility is not a valid concern (IMHO). I have
already posted *one* possible method of attaining this goal.
Also. I don't want to have my package build break just because
the sysadmin happened to have upgraded the system, and I need to get
a critical bug fix in, and don't have time to change things to match
the policy till the weekend.
My contention is, there is always going to be a delay for a
policy change to propogate (takes time for people to get new
packages, mirror sites lag a couple of days, maintainer busy for a
week or so, etc).
The developer is the only one who can co-ordinate conformance
with policy upgrades; we have to make it easier for him/her, not make
their job harder by changing the system around them. Giving the
maintainer control over when the upgrade to new policy happens,
rather than subtly breaking the package build process, seems a better
solution.
Bruce> I would prefer to see a run-time hueristic something like
Bruce> debstd with much more fine control over overrides.
And I prefer a compiler that allows
a) The package build process to be independent of the presence of the
tool
b) Increased auditability
c) Easy modification of the build process
d) Preservation of user changes.
e) The build not to subtly fail because of version mismatches.
If the helper tools run at run time can meet the above
requirements, than lets have at them. I have no particular liking for
the compiler; it just felt a better technical solution.
We can do this. Let us not compromise unless we have
to. Please consider the alternative before deciding on am
implementaion. What we need right now is what you think the system
should do, and when *all* that is in, we decide on a method to
implement it.
manoj
working hard on the requirements document, out later today
--
"If we are to begin packaging ourselves as boxes of cereal, Democracy
will die... for you could not win the presidency without proving
unworthy of the job." Adlai Stevenson
Manoj Srivastava <url:mailto:srivasta@acm.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
Reply to: