Re: On compilers, VM's, etc. (Was: Next app.: Doc. Policy)
Raul Miller writes:
> Raul Miller writes:
> > > source tends to refer to human-authored documents, compiled refers to
> > > machine translations of those documents. Don't lose sight of this, it's
> > > important for a variety of reasons.
>
> Yann Dirson <dwitch@bylbo.nowhere.earth> wrote:
> > IMO, this distinction is necessary from the point of view of
> > distribution maintainers. I will not contest that, and a simple
> > boolean control-field in packages will handle that well.
> >
> > But I do not think it is necessary from the user point of view. What
> > they need is just something that cat be run by the VM they choose; I
> > mean that from both doc and binary point of views.
> >
> > I they *really* want to get the source for any purpose, the
> > install-tool will just have to follow links down to the original
> > source-packages.
> >
> > Note here that I consider that a single tool will be needed for all
> > packages, no matter how much conversions lead to them.
>
> This is all fine from the user point of view, but the maintainer side
> of things needs to be packaged for a simpler (all-terrain) tool set.
>
> Alternatively, from the end user point of view, simplicity lies in
> automation. Here, you want minimal effort between user interest in
> some package and package up and running.
>
> [Of course, maintainers need automation too -- but that's for the
> tools that they use, rather than the source for the packages they
> work on. The only really good automation I'm aware of for package
> source has to do with getting updates expediently.]
Not only the maintainer needs to get access to the source. If we build
something allowing to handle source-packages consistently, it would be
available to the maintainers too.
IMHO, the user might want to look at the sources, eg.
- the emacs-czech package, whose info-file is in czech. One might want
to use it without a sufficient knowledge of czech to read the
info-file, and will find some english doc as comments and docstrings
in the source
- anyone, who, for security reason, wants to get sure of how a
particular program behaves, will want to get the sources
- anyone running a fully-libc5 really short-in-resources machine
wanting a newly available package compiled with libc6 might want to
recompile it before installing
- the user might be a programmer wishing to contribute to upstream
releases
Thus, I think we should make source packages easily available for
download to the user. The latter example illustrate the use of
dependencies on source-packages.
Anyway, a maintainer taking over maintainance of an old package WILL
gain something from such a framework.
My proposal would allow all of this in a homogeneous manner.
> However, from the maintainer
> point of view, simplicity lies in the data: clean layout, simple
> (portable) formats, etc.
Why ? I think most debian-package maintainer do their
maintainance-work on debian systems... If a "foreign" developer wants
to get debian sources, I guess he already has plenty of stuff on his
system (especially gcc and friends), and I think that just making the
install-tool available as non-debian {source,binary}-package will be
good enough.
Surely, this would need to put some support in the install-tool for
non-deb systems, allowing the user to bypass dependencies easily *on
such systems*.
--
Yann Dirson <dirson@univ-mlv.fr>
http://monge.univ-mlv.fr/~dirson
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: