Re: Bug#111274: ITA: doc-linux-ja -- Linux HOWTOs in Japanese
retitle 110941 ITA: doc-linux-zh -- Linux HOWTOs in Chinese thanks zw Martin Michlmayr [EMAIL PROTECTED] writes: * #110941: O: doc-linux-zh -- Linux HOWTOs in Chinese
Re: Lightweight Web browsers
Oh I know about ratpoison :) Of course one can always do the 'xterm' style of window managing (ie, extensive use of the -geometry option :) Nay, I haven't ever done even once -geometry thingy. Always maximise. Why not? Those apps can't do it sucks. :) (Though I'd really hope ratpoison could come over it, maybe a container alike applet for things such as Gimp etc.? Ie a lightweight xnest + a lightweight window manager(!!) would be helpful.) ohh my god, plus things as 9menu this ohh, this. ;) P.S. ratpoison really rocks, but please pay less attention on how you could kill the mouse. effort on this direction seldom gains IMHO. -- http://sourceforge.net/projects/dim .. Debian Chinese Input Method http://sourceforge.net/projects/cdlinux .. Debian running on Live! CDs http://njlug.sourceforge.net NanJing GNU/Linux User Group http://people.debian.org/~zw .. XEmacs Screenshots
Re: Gnome bug 94684
Bureaucracy is integral to an organization such as Debian. I beg to disagree. :) -- http://sourceforge.net/projects/dim .. Debian Chinese Input Method http://sourceforge.net/projects/cdlinux .. Debian running on Live! CDs http://njlug.sourceforge.net NanJing GNU/Linux User Group http://people.debian.org/~zw .. XEmacs Screenshots
Re: character sets
Brian May [EMAIL PROTECTED] writes: Now I have the unstable xemacs21-gtk mule installed, I only have mule input methods for Japanese and Chinese. Just FYI, most Chinese users use XIM based IMs, instead of Emacs based IMs. Emacs IMs for Chinese lags very behind in comparing. -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: Lightweight Web browsers
I too agree that Linux window managers and session managers should not aspire to emulate Microsoft, I'd rather see some newer and better ideas implemented instead. apt-get install ratpoison. it rocks. :) sorry, can't resist. ;) -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
What about other kernel modules packages that are part of debian? Will we need 6 or 7 pcmcia-modules-2.2.3-* packages, for example? that's difficult to resolve. take alsa for example. if user compiles their own kernel, then they will have to compile their own alsa. since the protocol used in between alsa kernel modules and alsaplayer are version dependent, the user will have to figure it out and compile their own version of alsaplayer, ... if we build alot of binary kernel, then we will have to build alot of alsa-modules too. it will take more mirror space. even though it's better than the above, it's still not perfect, and you know a kernel-image deb is more than 7M to download, ... i vote for alot of binary kernels. but i'd rather see someone comes out will better ideas. -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: Gnome bug 94684
You guys are getting more and more bureaucratic. That's sad. The package maintainer is a volunteer, and he knows you are also a developer. That said, why don't you report the bug directly to the upstream, instead of insisting on this (bureaucratic) procedure of reporting bugs to debian then waiting that debian developer to forward upstream while both of you debian developers are pretty sure it's an upstream issue? I agree that if you're a noname random clueless mere user then the package maintainer shouldn't just close this usibility bug blindly. Bureaucracy sucks. Relying on bureaucracy sucks even more. -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
this actually *helps* new users. Why? Because it teaches them to perform a task they should have to perform, at the right time. At some point, you *have* to stop tying your children's shoelaces, and teach them to do it for themselves. You obviously didn't read my previous post in this thread. Your point is ridiculous. You think linux kernel compiling is something as fundmental as tying shoelaces. rotfl. sorry. I can see your suggestion help mirrors (The trade-off is questionable.) But I can't see why it could help users. Questionable?!? Anything isn't questionable?!? ;) Have you seen ftp.au.d.o and mirror.aarnet.edu.au lately? (Admittedly, aarnet sucks and is broken half the time, but has the exact same breakage as ftp.au.d.o, which is normally fine). The mirrors which have trouble keeping up, and have out-of-sync packages, don't need *any* more load, least of all load like this. Okay I have to agree I'm not very aware of the sufferings of our mirrors. I left this for those who know better to decide. I certainly don't think that make users (even make the task easier) to compile a kernel can do help to most of the users (That is *not* a task they should be bothered at all.) And I certainly disagree that they who don't want compile a kernel don't belong to our user base. There's a *reason* RedHat exists. But that's not the reason that Debian can't do better. BTW, we're already asking them to understand the installer and dselect (and I have had to help some of my friends, all of whom who were very good at Linux, through this), so why not the kernel? If the figures Craig's throwing around of 110meg per kernel version are true, then that's absolutely unacceptable. Think of: out-of-sync mirrors (they don't need more load, or bloat to fill up the bandwidth and hard drives), and countries that pay by the meg for bandwidth. If we have no better way to go, we educate users that computer is dumb/stupid/dangerous/broken, take care of yourself. But this is *NOT* something to be proud of. please. But yes if the mirrors do suffer from this ~100M kernel packages, we may actually have to tell our users the sad message maybe. Sure, I'll reconsider this argument when the new debian-installer is ready (which sounds great already), but right now, no way. I guess we're not talking about installers. The above said. I may actually agree with you, if o the preformance difference of optimized kernel and general i386 kernel is so trivial that users can't even notice in their day to day work. and/or o the hits on the mirror is untolarable technically/financially. I won't agree the following though o users need to be educated/trained to compile the kernel for themselves. the reason i've stated in my previsous posts to this thread. -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
Vince Mulhollon [EMAIL PROTECTED] writes: I think the problem is a lack of cultural understanding. I appreciate your interpretation. Though I think I could give a even lengthier explanation to argue against. :) Thanks, -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
This is exactly our disagreement. My position is that it is well within our capabilities to make this unnecessary. And you disagree with that which is fine with me. [snip] I should build my own kernel, right? Sure, you're a computer geek. But remember we don't expect our users to be all computer elites. No, they're no dummies. Think about scientists, etc. who just simply don't have that much enough time sometimes to make oneself be familiar with kernel compiling. And why bother? (Ie. in most cases.) Regards, -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
I should build my own kernel, right? Sure, you're a computer geek. But remember we don't expect our users to be all computer elites. No, they're no dummies. Think about scientists, etc. who just simply don't have that much enough time sometimes to make oneself be familiar with kernel compiling. And why bother? (Ie. in most cases.) If they're not into madly trying to get the configuration perfect when it comes to the kernel, why install an optimized version at all? Because they are there. :) Ie. If we can do our users a favor.. (And if the trade off of bloating package pool is okay enough. In this case, I agree with Herbert.) -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Bug#94911: O: drscheme -- lost interests and don't use it anymore
Package: wnpp Severity: normal drscheme has quite some porting related bugs. and the upstream is moving fast to v200. i hereby orphan this package for i didn't use it for a long time. and i have to get more time work on other tasks which i have more interests. (for now at least. ;) thanks, -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Bug#94912: ITP: garlic -- free molecular visualization program
Package: wnpp Severity: wishlist Garlic, a free molecular visualization program written for unix and unix clones. Garlic was written by Damir Zucic, at the University of Osijek. The latest version of garlic may be found at: http://pref.etfos.hr/garlic -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
I agree that it is not too hard to compile your own kernel. I never use Debian's standard kernel-image packages (except on my 68K Mac, where it takes too long to recompile). Hey, hey, it's for you! Do you guys really expect all Debian users == Debian develoepers? What about k12 users? What about, say Donald E. Knuth? Do you really think that trivial cubersome kernel compiling ability is necessary for all to enjoy? They may just have no time, they may have no interests! Please don't even try to educate(??) them on this, OK? That said. If you guys are really into Craig's kernel-helper idea, go ahead with it. It yes could help you and me. But it still would make nonsense to many and they may still be in favor of pre-compiled, optimized (maybe trivially or whatever I left this to Herbert to decide) binary kernel. If you argue this for bloat, now look on XEmacs, just for example. There could be a single xemacs-mule-canna-wnn instead of xemacs-nomule, xemacs-mule, and xemacs-mule-canna-wnn. Right? Wrong! Becasue if we could do all users a favour, then why not? Isn't this the whole point of Debian? (But I agree the number of kernel packages for now is tunable, which Herbert seems be doing.) -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
Re: kernel-{image,headers} package bloat
this actually *helps* new users. Why? I can see your suggestion help mirrors (The trade-off is questionable.) But I can't see why it could help users. I certainly don't think that make users (even make the task easier) to compile a kernel can do help to most of the users (That is *not* a task they should be bothered at all.) And I certainly disagree that they who don't want compile a kernel don't belong to our user base. -- http://dim.sourceforge.net ... Debian Chinese Input Method http://njlug.sourceforge.net NanJing GNU/Linux User Group http://cdlinux.sourceforge.net ... Debian running on Live! CDs http://people.debian.org/~zw .. XEmacs Screenshots
debian changelog mode
Where could I get one? Thanks! Even no package for it is okay! ;) -- echo EOF |cpp - -|egrep -v '(^#|^$)' /* =|=X ++ * /\+_ p7 [EMAIL PROTECTED] */ EOF
Re: big Packages.gz file
From: Hamish Moffatt [EMAIL PROTECTED] Subject: Re: big Packages.gz file Date: Tue, 9 Jan 2001 23:40:01 +1100 On Tue, Jan 09, 2001 at 06:04:58PM +0900, Miles Bader wrote: The packages file gets downloaded _every single time_ you do an update, and for those of us with a slow modem link, that really sucks. This is only a small part of the whole story, IMHO. See my other email replying you. ;) Maybe there could be another version of Packages.gz without the extended descriptions -- I imagine they would take something like 33% of the Packages file, in line count at least. Exactly. DIFF or RSYNC method of APT (as Goswin pointed out), or just seperate Descriptions out (as I pointed out and you got it too), nearly 66% of the bits are saved. But this is only a hack, albeit efficient. Cause this does not solve the problem of the package pool within the package pool system. It does it on the protocol and client tool side. 1) AIUI, package pool should be a storage system, which should has a smart algorithm for deleting packages which no distribution or other packages referncing. (Garbage collection by reference counts.) 2) A distribution, put aside the work of our honoured release manager, should be a partial package index listing. Thus, should be seperated from storage system. The current ``testing'' distribution doesn't to it well enough. (Thus, it has a regulation on upload frequency.) With these two things in mind, RSYNC can help very little. And the package pool's indexing problem remains. While on my previous letters, I try to get out a discussion on one of my humble try to help. ;) As soon as I have enough time, and enough discussion, I maybe write a more prepared document. But I need discussion first. Thanks! -- echo EOF |cpp - -|egrep -v '(^#|^$)' /* =|=X ++ * /\+_ p7 [EMAIL PROTECTED] */ EOF
Re: big Packages.gz file
From: Hamish Moffatt [EMAIL PROTECTED] Subject: Re: big Packages.gz file Date: Tue, 9 Jan 2001 19:59:13 +1100 On Tue, Jan 09, 2001 at 03:04:10AM +0800, zhaoway wrote: A big package index IMHO is the current bottleneck of Debian package system. What is the real problem with the large package files? They take a long time to download, but so do emacs and other bloatware. The problem is, IMHO, that is, ;) Every awhile, when you want to update a package to the newest version, you have to update the package index first. And that is not absolutely necessary if you look into this problem. And the size of package index is constantly growing. With Emacs, nearly all of the bits are necessary for the functionality, and you don't download it for evey trivial update tasks. And it is not as rapidly growing in size as package index is. To look further, if we allow translation of Packages index, it could be even bigger. Or we allow multiple versions of a package come into Package pool (as Manoj had mentioned in another thread), big Package index could be even more troublesome. Hope I make myself clearer. ;) And thank you for discuss with me! ;) -- echo EOF |cpp - -|egrep -v '(^#|^$)' /* =|=X ++ * /\+_ p7 [EMAIL PROTECTED] */ EOF
Re: RFDisscusion: Big Packages.gz and Statistics and Comparing solution
On Mon, Jan 08, 2001 at 12:53:52AM +0100, Marcin Owsiany wrote: Something like this should be implemented anyway when translated Descriptions will be supported and Packages size will grow by some 6 times. Oh, man, you got another strong point against general package index. (Big Packages.gz could be overwhelmingly big. hehe.. ;) -- echo EOF |cpp - -|egrep -v '(^#|^$)' /* =|=X ++ * /\+_ p7 [EMAIL PROTECTED] */ EOF
Re: big Packages.gz file
On Sun, Jan 07, 2001 at 05:18:02PM -0500, Chris Gray wrote: Brian May writes: bm What do large packages have to do with the size of the index file, bm Packages? I think the point was that every package adds about 30-45 lines to the Packages file. You don't need to download any of the Linux Gazette to have the 33 lines each issue takes up in the Packages file. A big package index IMHO is the current bottleneck of Debian package system. While most of people are more interested in RSYNC to come to cure, MHO RSYNC is an overkill and a non-clean-kill. It prevents easy mirroring of Debian by requesting RSYNC service on the mirror system, and it won't solve the pool's problem, but give a hack. ;) While OTOH a relatively straight solution is: * To seperate Packages.gz to be along with each package as another seperate file. Ceazar's belong to Ceazar. ;) i.e., each pkg_ver-sub_arch.deb with a pkg_ver-sub_arch.idx * At the same time, provide a big Packages.gz by collecting these small files for compatibility. Or, maybe even a trimmed Packages.gz by removing all of the Description:s. * Optionally, provide hard or symlinks along with each package, some i.e., pkg_[stable|unstable|testing]_arch.idx - pkg_ver-sub_arch.idx Note: this won't hurt mirror, OTOH could even help partial mirror. * And enable multiple versions of a package in the package pool. This way, general package index is optional. And release management could move towards those more fine tuned task-* like packages. No lost. ;) Just for discussion, I would be glad to hear critics. ;) -- echo EOF |cpp - -|egrep -v '(^#|^$)' /* =|=X ++ * /\+_ p7 [EMAIL PROTECTED] */ EOF
RFDisscusion: Big Packages.gz and Statistics and Comparing solution
Hi, [Sorry for the thread broken, my POP3 provider stopped.] [Please Cc: me! [EMAIL PROTECTED]. Sorry! ;-)] 1. RFDiscussion on big Packages.gz 1.1. Some statistics % grep-dctrl -P -sPackage,Priority,Installed-Size,Version,Depends,Provides,Conflicts,Filename,Size,MD5sum -r '.*' ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages | gzip -9 test.pkg.gz % gzip -9 ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages % ls -alF *.gz -rw-r--r--1 zw zw1157494 Jan 7 21:20 ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages.gz -rw-r--r--1 zw zw 341407 Jan 7 21:23 test.pkg.gz % This approach is simple and straight and almost compatible. But could accpect 10K more packages come into Debian with little loss. Worth consideration. IMHO. Better, if `Description:' etc. could come into seperate gzipped file along with the Debian package. 1.2. Little math Suppose: 1) Site A get K hits of `apt-get update' per day. With everyday passed, M extra hits added, as Debian goes more popular. 2) N new packages come into Debian every day. After `gzip -9', each contribute 206 byte to old package index file, and 61 to new format index file. Current package number is P. 3) Days passed as X axis. 4) B as the byte size of the data flow for `apt-get update' for that day. On the server side. (Client side K =1, M = 0) B = (K + M*X) * (P + N*X) * 206 is for old format package index B = (K + M*X) * (P + N*X) * 61is for new format package index [It's still X^^2 function, anyway, so it's, in theory, not a big deal. ;-)] [Only if we could eliminate the need for Package Index. That is possible. ] For K = 500, P = 6000, X = 0, Server side B is, [EMAIL PROTECTED] ~/tmp % echo $((6000*500*206)) 61800 [EMAIL PROTECTED] ~/tmp % echo $((6000*500*61)) 18300 [EMAIL PROTECTED] ~/tmp % [Though the caches could help a great lot for servers in such cases.] 2. Compare with DIFF and RSYNC method of APT 2.1. They need server support. (More than a directory layout and client tool changing.) 2.2. If you don't update for a long time, DIFF won't help. RSYNC help less. 3. Additional benefits Seperate changelog.Debian and `Description:' etc. out into meta-info file could help users: 1) reduce the bandwidth eaten 2) help their upgrade decisions easily. -- echo EOF |cpp - -|egrep -v '(^#|^$)' /* =|=X ++ * /\+_ p7 [EMAIL PROTECTED] */ EOF
Re: RFDisscusion: Big Packages.gz and Statistics and Comparing solution
[A quick reply. And thanks for discuss with me! And no need to Cc: me anymore, I updated my DB info.] On Sun, Jan 07, 2001 at 05:51:26PM +0100, Goswin Brederlow wrote: The problem is that people want to browse descriptions to find a package fairly often or just run apt-cache show package to see what a package is about. So you need a method to download all descriptions. The big Packages.gz is still there. No conflict between the two method. And the newest, most updated information is always on freshmeat.net. ;) As far as I see theres no server support needed for rsync support to operate better on compressed files. Um, I don't know. But doesn't RSYNC need a server side RSYNC to run? Or, can I expect a HTTP server to provide RSYNC? (Maybe I am stupid, I'll read RSYNC man page, later.) If you update often, saving 1 Byte every time is worth it. If you update seldomely, it doesn't realy matter that you download a big Packages.gz. You would have to downlaod all the small Packages.gz files also. There is an approach to help this. But that is another story. Later. So you see, between potato and woody diff saves about 60%. Also note that rsync usually performs better than cvs, since it does not include the to be removed lines in the download. Pretty sounding argument. My only critic on DIFF or RSYNC now is just server support now. (Again, I'll read RSYNC man page later. ;-) The point is, can a storage server which provides merely HTTP and/or FTP service do the job for apt-get? -- echo EOF |cpp - -|egrep -v '(^#|^$)' /* =|=X ++ * /\+_ p7 [EMAIL PROTECTED] */ EOF
big Packages.gz file
[sorry, either fetchmail or my ISP made me lost 30 or so emails.] The problem with bigger and bigger Packages.gz, [I thought is obvious. :-(] is, 1) It prevent many more packages to come into Debian, for example, Linux Gazette are now not present newest issues in Debian. People occasionally got fucked up by packages like anachism-doc because the precious band-width. And some occasional discussion on L10N packages to distrub others life who don't need it. 2) It don't scale. Release managment is difficult. RM in general only considering RC bugs on most of the packages he is not familiar of. ;-) Now considering mechanisms such as DIFF and RSYNC of Packages.gz 1) They're difficult to setup, though it _should_ be easier considering it's an end-user stuff. With the current state of testing, i.e., often updated Packages.gz and a more or less stable state, that people tends to update very often. 2) They have a FIX TIME problem. I.e., if you don't RSYNC or DIFF for a long time, they won't save you extra bandwidth. While my approach do. 3) They don't scale just as well. ;-) Now considering mechanism to section Packages.gz by functionality or just like Package pool does. 1) Due to the complicated Dependency problem, they're deemed to fail. ;-) Okay, now see my approach. [See my previous mail. The FINAL one. ;-)] 1) They're compatible with old tools. (Only you discuss with me!!) 2) It scales well. To release managment, and to include just as many as our hard disks permitted packages into Debian. 3) It is very easy for enduser to setup. 4) No extra burden on Developers as how frequently they should do upload. 5) No FIX TIME problem. (See above.) 6) Possibilies exist for package to provide changelog to users for their consideration to if to upload. These will help developers to avoid some fake bug reports. So why not bother discuss with me? ;-) zw
package pool and big Packages.gz file
hi, [i'm not sure if this has been resolved, lart me if you like.] my proposal to resolve big Packages.gz is through package pool system. add 36 or so new debian package, namely, [a-zA-Z0-1]-packages-gz_date_all.deb contents of each is quite obvious. ;-) and a virtual unstable-packages-gz depends on all of them. finished. apt-get update should deal with it. 1) as default, install packages-gz.deb, and finished. (against some policy ...) 2) otherwise, let user to choose from, that is a ui design... ;-) release managment could just ;-) upload a woody-packages-gz_test-1_all.deb episode I finished. episode II involves the package pool deletion algorithms. a package should only be deleted when no *-packages-gz debs reference it. my 2'c thanks for bear with me ;-) zw
Re: package pool and big Packages.gz file
[read my previous semi-proposal] this has some more benefits, 1) package maintainer could upload (to pool) in whatever frequency they like. 2) release is seperated from package pool which is a storage system. and release is a qa system. 3) release could be managed through BTS on specific package-gz.deb that surely would put much more burden on BTS, ;-) 4) if apt-get could deal it well, i hope all of sub-mirror'ing issue will be gone easily. just apt-get install some-rel-packages-gz then apt-get mirror (just like download and move ...) my more 2'c ;-) zw
Re: package pool and big Packages.gz file
On Fri, Jan 05, 2001 at 03:17:30AM +0800, zhaoway wrote: [read my previous semi-proposal] this has some more benefits, 1) package maintainer could upload (to pool) in whatever frequency they like. in an ideal world, developer should upload to ''xxx-auto-builder'' ;-) 9i'm turning out to be crappy now. ;-) bye,
Re: package pool and big Packages.gz file
On Thu, Jan 04, 2001 at 11:01:15PM +0200, Sami Haahtinen wrote: On Fri, Jan 05, 2001 at 03:02:15AM +0800, zhaoway wrote: my proposal to resolve big Packages.gz is through package pool system. add 36 or so new debian package, namely, [a-zA-Z0-1]-packages-gz_date_all.deb contents of each is quite obvious. ;-) and a virtual unstable-packages-gz depends on all of them. finished. apt-get update should deal with it how about diffs bethween dinstall runs?.. sorry, but i don't understand here. dinstall is a server side thing here? packages-010102-010103.gz packages-010103-010104.gz packages.gz apt would download the changes after the last update, and merge these to the package file, if the file gets corrupted, it would attempt to do a full update. This wouldn't be a big difference in the load that the master-ftp has to handle, atleast when some 7 of these would be stored at maximum. okay, try to group packages according to dependency, on the top, some pkg-gz-deb lists packages on the leaf of dependency tree, and each of pkg-gz-deb won't get bigger than 100k, and each of them depends on some more basic pkg-gz-deb below, some other pkg-gz-deb like the base sub-system. this way, when user install xdm, apt-get first install pkg-gz-deb which lists xdm, then as dependency checking, it will install base-a-pkg-gz-deb etc. ect., then xdm got installed, this way, all xdm's dependency will be fulfiled with the newest information avalaible. and you can see this will surely ease up the band-width. (when update gcc, i won't get additional bits of Packages.gz about xdm xfree etc.) regards, zw
Re: package pool and big Packages.gz file
On Thu, Jan 04, 2001 at 11:19:59PM +0200, Sami Haahtinen wrote: how would the package manager (namely apt) know which ones you need.. even if you don't have X11 installed (and apt assumes you don't need X11 packages file) doesn't mean that you wouldn't want to install x11 packages file. another solution is to let every single deb provides its.pkg-gz then, apt-get update will do nothing, apt-get install some.deb will first download some.pkg-gz, then check its dependency, then grab them.pkg-gz all, then install. and a virtual release-pkgs-gz.deb will depend on some selected part of those any.pkg-gz to get up a release. then katie will remove a package only when no release-pkgs-gz.deb (or testing, or whatever) depends on its.pkg-gz regards, zw
Re: package pool and big Packages.gz file
On Fri, Jan 05, 2001 at 06:07:20AM +0800, zhaoway wrote: another solution is to let every single deb provides its.pkg-gz then, apt-get update will do nothing, apt-get install some.deb will first download some.pkg-gz, then check its dependency, then grab them.pkg-gz all, then install. that is a minimum. isn't it? ;) and then we will need some ``apt-get info pkg'' hehe.. and a virtual release-pkgs-gz.deb will depend on some selected part of those any.pkg-gz to get up a release. say one release contains 2000 pkgz, each pkg name is 10 chars, then the whole infomation is a little more then 20k, compare with nowadays, a more than 1M. and you could have base-3.3-release, and gnome-4.4-release which depends on base-3.2-release and x-5.6-release. and chinese-2.0-release etc. ... then katie will remove a package only when no release-pkgs-gz.deb (or testing, or whatever) depends on its.pkg-gz zw
Re: package pool and big Packages.gz file
[quote myself, ;-) this is semi-final now ;-)] another solution is to let every single deb provides its.pkg-gz then, apt-get update will do nothing, apt-get install some.deb will first download some.pkg-gz, then check its dependency, then grab them.pkg-gz all, then install. that is a minimum. isn't it? ;) and then we will need some ``apt-get info pkg'' hehe.. and a virtual release-pkgs-gz.deb will depend on some selected part of those any.pkg-gz to get up a release. say one release contains 2000 pkgz, each pkg name is 10 chars, then the whole infomation is a little more then 20k, compare with nowadays, a more than 1M. and you could still do ``apt-get dist-upgrade'', just first install release-pkgs-gz.deb then go on..., OR, first get a list of all debs installed then update them each. [some more thoughts here..., later] and you could have base-3.3-release, and gnome-4.4-release which depends on base-3.2-release and x-5.6-release. and chinese-2.0-release etc. ... then katie will remove a package only when no release-pkgs-gz.deb (or testing, or whatever) depends on its.pkg-gz zw
Re: package pool and big Packages.gz file
On Thu, Jan 04, 2001 at 11:19:25PM +0100, Petr Cech wrote: On Fri, Jan 05, 2001 at 06:07:20AM +0800 , zhaoway wrote: then, apt-get update will do nothing, apt-get install some.deb will first download some.pkg-gz, then check its dependency, then grab them.pkg-gz all, then install. but it will immensly restrict it's view on dependencies - think about virtual packages. This is really not the way. Maybe spliting by as in pool/ so you only download changed part of the whole thing. But that's about it. Maybe you can leave some part out, but .. virtual package is weird here. ;-) but could be resolve by a some-virtula.pkg-gz ;-) and the tree view of dependency tree, like in console-apt, that means, [see my another semi-final mail.. ;-)] in general, if you wanna an tree-view of the whole tree, you will need to download the whole tree anyway, and my approach won't prevent you do that. ;-) kinda regards, zw
[FINAL, for now ;-)] (Was: Re: package pool and big Packages.gz file)
final thoughts ;-) On bigger and bigger Packages.gz file, a try The directory structure looks roughly like this: debian/dists/woody/main/binary-all/Packages.deb debian/pool/main/a/abba/abba_1989.orig.tar.gz abba_1989-12.diff.gz abba_1989-12.dsc abba_1989-12_all.deb abba_1989-12_all.pkg debian/pool/main/r/rel-chinese/rel-music_0.9_all.pkg rel-music_0.9_all.deb rel-base/rel-base_200_all.pkg rel-base_200_all.pkg Contents of rel-chinese_0.9_all.pkg is as following. rel-base or even rel-woody is just much more complicated. Hope so. rel-chinese.deb is nearly an empty package. Package: rel-music Priority: optional Section: misc Installed-Size: 12 Maintainer: Anthony and Cleopatra Architecture: all Source: rel-chinese Version: 0.9 Depends: rel-base (= 200), abba (= 1989-12), beatles(= 1979-100), garbage(= 1998-7) wearied-ear (= 2.1) Provides: music | abba | beatles Filename: debian/pool/main/r/rel-chinese/rel-music_0.9_all.deb Size: 3492 MD5sum: c8c730ea650cf14638d83d6bb7707cdb Description: Simplified music environment This 'task package' installs programs, data files, fonts, and documentation that makes it easier to use Debian for Simplified music related operations. (Surprise, surprise, garbage didn't provide music!) Note, music is a virtual package provided by adda and beatles. Contents of abba_1989-12_all.pkg is as following. Package: abba Priority: optional Section: sound Installed-Size: 140 Maintainer: Old Man Billy Architecture: all Version: 1998-12 Replaces: beatles Provides: music Depends: wearied-ear (= 2.0) Filename: pool/main/a/abba/abba_1989-12_all.deb Size: 33256 MD5sum: e07899b62b7ad12c545e9998adb7c8d7 Description: A Swedish Music Band ABBA is popular in 1980's in last millenium. Don't be confused by ABBA and ADDA which is a heavy metal band. Here, music is a virtual package provided by packages abba and beatles. Let's simulate some typical senarios here. 1) apt-get update There're roughtly two purpose for this action. One is to get an overview, to ease up further processing like virtual packages; another purpose is to install a specific package, or do dist-upgrade. On the second purpose, apt-get here will do nothing. (See below) On the first purpose, apt-get will have to download and parse the current distribution's .pkg file according to user configuration. Say, to download rel-music, and then see the virtual package music is provided by abba and beatles. So, generally, ``apt-get update'' will deal with rel-some__all.pkg to get all of the overall information it will need further on. Then, where does the rel-some__all.pkg get its information? We don't want the release manager to track down all of these information. So, where's katie? ;-) I think the trade-off is worthy (Indeed, only katie get to be a little more complicated) considering the scalabily being gained. Read on. 2) apt-get install abba apt-get will first parse the previously downloaded rel-music.pkg, and get abba is at version 1998-12, and it depends on wearied-ear (= 2.0) and wow! rel-music happens to provide wearied-ear (= 2.1), that's okay. Then apt-get go on to download its .pkg and parse it, and so on. When all required .pkg were downloaded and parsed (an updated Packages.gz) apt-get then go on to download and install every of the debs. (Maybe there will be more complicated issues, only let me know. See what's going. ;-) Thus, minimum data downloaded. ;-) 3) apt-get dist-upgrade I don't know the details, but I think it's not very complicated given above information. (All necessary things are there, aren't they? ;-) 4) Packages upload .pkg file is generated automatically. No extra burden on most of the developers. And developers could upload just as frequently as they see fit. ;-) Katie will be a little ;-) more complicated. Package will get to be deleted from package pool only when no rel-X depends on them. rel-X are treated specially. And some fine tuned mirror could be setup. And release management could benefit from Bug Tracking System and more flexible. IMHO. ;-) Kind regards, zw
libglide2: debconf didn't ask question even for failed answer
hi, [no time to dig deeper, right now, bear with me] when installing libglide2 which uses debconf, i gave a answer which causes the package failed to be installed, then after the batch installation, i re-run apt-get to install it, but it didn't ask the question again. i consider this is fault ui design. i.e., if the question answer has bad effects, it _should_ be asked again all the way through no need for user to do special prior setup. IMHO. regards, zw
Re: Huh, gcc 2.95.3?
On Tue, Jan 02, 2001 at 12:18:51AM +0100, Matthijs Melchior wrote: Yes, OK, I was expecting a method that did not require to download the full package, just the index and a specific file then ask a mirror admin to provide the service (i.e. parse deb to get changelog etc. and post them, oops does package.debian.org do this already?) ;-)
