Robert Millan <[EMAIL PROTECTED]> writes: > apt-get source kernel-image-* doesn't bring me the real source. Instead, if > I want the real source I must be root and install a binary package. Do you > deny that this is confusing?
I don't understand why you must be root, could you elaborate? I am no expert in Debian kernel packaging, but why not fetch the source of kernel-image-*, see what kernel-patch-* packages it depends on and get the source of them and kernel-source-*? It is not what I would do, as I build my kernels with make-kpkg, but it doesn't seem impossible. To a new user this will all be confusing, but they should not compile their own kernels anyway. > But this is my discussion. If I don't take part in it, > who will respond to all these bogus arguments some people enjoy sending in? > > Rather, this is you and the other trolls who are wasting my time. Yeah, sure, if 90% of the people disagree with you, they must all be trolls. Reminds me of that guy on the wrong lane on the highway... > On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote: > > Now do go ahead and do tell me that the packaging is "easy to > > understand". Define "easy" then, because with the information I have > > at hand the only reasonable interpretation is "easy for Robert Millan > > to understand". > > It's easy for people who are already used to Debian de-facto standards. > Since I am and you're not [1], that makes a difference. Therefore don't > expect to understand it. > > [1] Your reasoning shows either you're not used to them, or you're plainly > trolling. I'll assume the first at your convenience. What makes you think that Marcelo doesn't use Debian standards? Do you have any evidence or is this just trolling on your side? > Some people publicly said in this thread they like the package. Many more stated the opposite opinion, but I guess you see them all as trolls. > Herbert said he likes it at least as an experiment. I got other > private mails from well-known developers who like my proposal and > pity your trolling attempts. Yeah, anonymous sources, and what does "well-known" mean? The cabal? People who hold an opinion on this and don't weigh in publicly can't be accounted for. (The exception being the ftpmasters who can just reject your package on upload...) > But the real results are shown through Popularity Contest [1] when my package > reaches unstable. So keep your arguments on this for later. > > [1] http://people.debian.org/~apenwarr//popcon/ Since when do we package everything and then see if it makes the popularity contest? In my opinion you are adding to archive bloat and this package should not hit unstable. Once it is there, it will take ages until it gets removed. Why not upload to experimental or such and if Herbert really likes it, then at some point it can replace the current kernel packages. I still see a lot of substantial problems, in particular the removal of the old kernel on upgrade. I never remove an old kernel before I have thoroughly tested the new one. Last example where this was necessary was the vanilla 2.4.22 which leads to hard lock-ups after suspend from sleep on this iBook. Not unusable but pretty annoying, and always good to have an older kernel to boot into handy. > I haven't even thought of my scheme as "becoming the preferred way of > distributing Debian Linux". So I'll ignore your bogus hipothesis. So you want to add to the archive bloat? Just to have the Linux kernel as a "standard" Debian package? So should we all start repackaging our favorite applications where the maintainer packaging or default configuration or compiler options are not to our taste? I hope you would not want that, but I see your package doing exactly that for the kernel. > But certainly, you must be very scared of that possiblity, since you're > wasting your time and inventing bogus arguments just to prevent it from even > being in Debian at all. Why is that wasting time? It is called quality assurance, first of all trying to keep non-needed stuff out of the archive, second (at least in my opinion) to make sure the maintainers understand their packages. (For the record, I consider your repeated statement that Herbert is the real maintainer and you are only the packaging monkey a quite lame excuse. I don't want Debian maintainers to be just repackagers, not for upstream, not for another maintainer.) > How is deinstalling a known-to-be working {libc,bash,coreutils} not an issue? libc and coreutils are an issue, less so bash. However, for the kernel there is a good mechanism to keep backup kernels and choose them in a bootloader. This is a feature, in my opinion, and that this doesn't work for other packages is no excuse to stop it from working for the kernel. > And as I've seen in some other message, quoting kernel-package generated > postinst, the current packages _do_ suffer of the same problem. Only if you update a new Debian revision of the same kernel version. Furthermore, you can always tweak EXTRAVERSION to make the name unique. > You know, I could have RTFMed inmediately and respond I know what System.map > is, but I don't see why this insignificant argument should actualy waste my > time in reading docs for the only purpose of proving I can read docs. You are making it worse with every post. So you think reading docs for your own packages is wasting time? Nice. OK, the rest of your message is more ignorance and arrogance, I will stop it here. Do you actually know what the project expects of its package maintainers? You seem to have a rather shallow understanding of all the issues involved with kernel packaging, and I strongly object to this package being uploaded to sid. Experimental would be fine with me for people to test it. Lukas
