Re: Possible framework for `debmake replacement'
On Feb 24, Manoj Srivastava wrote
> Michael> I think David's thinking in terms of the .spec file for RPMs.
> Michael> I couldn't say whether he's thinking of incorporating all the
> Michael> various files we already have into one big file from which
> Michael> the appropriate snippets would be snipped and placed in the
> Michael> DEBIAN/ directories, but it's a possibility.
>
> Umm, in this case, it is beyond the debmake replacement, and
> should go to the dpkg/dselect thread.
I don't agree. I'll rephrase what I tried saying ealier to support my
position.
IMO, the current format of .deb files is satisfactory. There are
things that we could improve upon, but there is nothing that we have
to change right now to accomplish the goals that are being discussed.
This being the case, I see two main areas of work to be done. One
which deals with how to build .deb files (this thread) and another
which deals with how to use/install/remove .deb files after they are
built (dpkg/dselect thread).
> Michael> What I think he's talking about, though, is not having to
> Michael> fill your debian/rules with cp's and mv's and ln's and so
> Michael> forth, but instead being able to operate at a "high level"
> Michael> when it comes to pecifying these things.
>
> In which case I object strongly. One of the things that lead
> to my current involvement is all the ``high'' level things happening
> behind the scenes. I want an automatic process, which requires less
> human involvement, but not necesarily a high level or opaque one.
Nobody said anything about opaque. If you want to see each individual
step, in all it's glory, then that can be arranged.
> I like to know what is happeining when I build
> packages. Something that reads a run control file and produces
> intermediate, human readable output that can be scanned as desired
> is, as the vernacular goes, goodness. Direct, or runtime generation
> of such output, is not.
Warning: sarcasm ahead. I see. Are you in the habit of always
running cpp, cc1, as and ld separately when you compile? You never
know what gcc might try to do behind your back. :-)
> Michael> In other words, I suspect, they should be official parts of
> Michael> dpkg---maintainers could use them with no risk of causing
> Michael> problems with people doing new ports or whatever.
>
> If you-all really mean dpkg, this is out of the scope of this
> requirements process.
By who's decision?
David
--
David Engel ODS Networks
david@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: