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

Re: new Debian user's thoughts on Debian installation



In Sun, 15 Oct 2000 13:37:03 -0400 "E. Jay Berkenbilt" <ejb@ql.org> cum veritate scripsit :

> What would work for me would be to always get the packages required to
> BUILD anything I choose to install, and to always get the -dev
> packages corresponding a runtime package.  I'll give some concrete
> examples.

This is partially implemented, and we are moving on. If a package does
not have the information in the control file, then it is considered a 
policy violation (a "bug").

It is in the source-package's "Build-Depends:".

However, supporting software is not updated enough to check this field,
but I presume support is going to come sometime. 

Currently 

apt-get source packagename

will get the source package, and this should probably automatically be 
fetching the packages required to build it. 

For now, you can check the Build-Depends: line in 
the source file's "packagename-version/debian/control" file, 
and yank the contents, and do an apt-get install.

> I use openssh which doesn't seem to exist even in the non-US area
> (unless I just missed it).  openssh links with libwrap.  I got the
> libwrap runtime libraries because of TCP wrappers, but I did not get
> the development libraries.  I had to go back and install the
> development libraries.  Additionally, openssh has a gnome askpass
> program.  I couldn't build it because gnome-config didn't get
> installed.

openssh is (AFAIK) the "ssh" package.

Try "apt-cache search openssh", and you will see

$ apt-cache search openssh
ssh - Secure rlogin/rsh/rcp replacement (OpenSSH)
ssh-askpass - under X, asks user for a passphrase for ssh-add

that there are two packages which have the keyword "openssh" in the description.

Binary packages are binary packages, and obviously they don't need
developer packages installed. (not everyone develops). Source packages
surely do need the develper packages. 

Methinks it will be improved soon... For the moment, you can read 
debian-mentors mailing list archives to see how people are discussing the
details of how to implement an "auto-builddependency-checker" and how
difficult it is.

> However, since this
> is quite subject to the packager who could easily forget since he/she
> probably already has all the development stuff installed, I've also
> suggested that you should automatically get developer libraries for
> runtime libraries if you are a developer.  There.... that was not the
> most clearly written paragraph I've ever produced, but I hope the
> point is clear.

So, there is a preliminary program which checks what files were 
accessed while building a package, and lists all the package names
that have the accessed files included (which probably are the 
packages required for build). It had some quirks (it only runs in root).

If you are a developer, and want to compile something, you probably need to
get the source package. 

> One could conceive of a similar type of flag for automatically getting
> -doc packages that correspond to runtime packages.  Likewise, server
> packages that go with client packages....  With rpm, you can generate
> multiple binary packages from one source package.  

You can do that with dpkg too.

> I virtually always
> install all binary rpms that go with a single source rpm which pretty
> much gives me this functionality. 

That's not very useful... I guess they were divided for a reason, and that 
should be respected.
"-doc" package probably means, it's not really needed. It's optional, or 
it will be depended by the main package.

> If any of what I've said above is wrong, represents a
> misunderstanding, or is otherwise solvable under the current system,
> I'd be grateful if someone could set me straight. :-)

;)

> 
> Another thing is that it would be nice to control the order in which
> the sections are presented.  Using "o" from dselect and selecting Sort
> by (avail., section) helps some, but I found that an alphabetical
> presentation still wasn't what I wanted.  

I don't use dselect... use "apt", it's better.

apt-cache search <keyword>   to search for what's required, and
apt-get install <packagename> to install a package.

Nice and command-line ;)

> Another thing that would be really nice to see in the installation
> environment would be a running total of the amount of disk space
> change that the selections will cause.  

apt-get tells you like this :

$ apt-get install lilo
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
  lilo 
0 packages upgraded, 1 newly installed, 0 to remove and 142 not upgraded.
Need to get 120kB of archives. After unpacking 195kB will be used.


Is this what you wanted ?

> Some indicator during installation of percent complete would be
> helpful too.  RedHat has a slider with a percent complete and a time
> remaining estimate.  Obviously Debian can't do that because of the
> fact that the installation is interactive where as the package
> installation phase of RedHat's installation is completely hands-off.

Yes... it's probably impossible to make an estimate. 
It already has a download-time estimate, but there is no way
configuration time can be estimated. How do you estimate the amount of
time a user stays pondering around on a question ? 

We could have a "nnn out of nnn package configured  [*****-------------]"
like thing with apt. Wishlist?

> Well, if you've made it all the way to the end of this message,
> thanks.  I didn't think it was going to be so long when I started.  I
> hope these comments will be useful to the ongoing effort to improve
> Debian in general and the installation system in particular.

I made it to here! Yes. I thought what you have wrote was quite intersting,
although most parts were "user" question, rather than a "developer" question
IMO. 

I doubt many people would read this long message in this high-traffic list...


regards,
	junichi

--
University: ti0113@mail4.doshisha.ac.jp    Netfort: dancer@netfort.gr.jp
dancer, a.k.a. Junichi Uekawa   http://www.netfort.gr.jp/~dancer
 Dept. of Knowledge Engineering and Computer Science, Doshisha University.
... Long Live Free Software, LIBERTAS OMNI VINCIT.



Reply to: