[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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>

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: