Re: search-citeseer_0.1-1_i386.changes REJECTED
On Fri, 17 Oct 2003 12:22:33 +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: James is ftp-master, DAM, autobuilder admin, and part of the debian-admin team as well. He does the things he does the way he does them not because he doesn't like you, but because that's the most efficient use of his time. He doesn't have time to explain the nitty-gritty details of each and every decision he makes. Above all, he's got the most important property for any sysadmin: 'a reasonable amount of paranoia'. That might mean that at times he won't trust some of us, but I think that's a good thing, not a bad one. His only downside is that he's not so communicative, but hey, nobody's perfect. That man is too damn important. If there is no time to be polite, that needs to be changed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: search-citeseer_0.1-1_i386.changes REJECTED
Marc Haber [EMAIL PROTECTED] writes: On Fri, 17 Oct 2003 12:22:33 +0200, Wouter Verhelst [EMAIL PROTECTED] wrote: James is ftp-master, DAM, autobuilder admin, and part of the debian-admin team as well. He does the things he does the way he does them not because he doesn't like you, but because that's the most efficient use of his time. He doesn't have time to explain the nitty-gritty details of each and every decision he makes. Above all, he's got the most important property for any sysadmin: 'a reasonable amount of paranoia'. That might mean that at times he won't trust some of us, but I think that's a good thing, not a bad one. His only downside is that he's not so communicative, but hey, nobody's perfect. That man is too damn important. If there is no time to be polite, that needs to be changed. Oh, please, I don't find his reply impolite, just factual. -- Rémi Vanicat
Re: search-citeseer_0.1-1_i386.changes REJECTED
Henning Makholm wrote: Scripsit Agustin Martin Domingo [EMAIL PROTECTED] Last time I read about that, if is byte compiled it should depend on virtual package 'emacsen' (provided by all emacs flavours), since otherwise emacs-package-install failed if no emacsen was installed. If that is true, shouldn't it be counsidered a bug in emacsen-common? I could finally take a look at this. The failure appears only when the package providing the extra lisp file (name it 'the_package' for simplicity) tries to run emacs-package-install before emacsen-common is fully configured. This is fixed with a dependency on emacsen-common in 'the_package'. Sometimes this might not be desirable, e.g. when 'the_package' is of priority 'standard', since it would pull a 'optional' priority package like emacsen-common. This could have been the reason that made Peter split his package. What I mean is that if the emacsen-common configure check is done in the postinst (checking if /var/lib/emacsen-common/installed-flavors is present), even that dependency could perhaps be avoided. As a matter of fact the above snippet is the debhelper snippet slightly modified for that check. You can try a workaround like this if [ $1 = configure -a -x \ /usr/lib/emacsen-common/emacs-package-install ] This wouldn't work - if the package was installed before emacsen-common, its files would never be byte-compiled even if emacs was later added to the system. I am not that sure, unless I am missing something, the files will be byte-compiled as soon as an emacs flavour (name it 'emacsen' for simplicity) is installed, since then all /usr/lib/emacsen-common/packages/install/* scripts will be re-run (appropiately sorted) for the installed flavour. (And there's no telling whether things would break horribly if emacsen-common happened to be unpacked but not yet configured when the postinst script runs). In that case nothing would happen until an emacsen is installed, where all remaining lisp files will be byte compiled for its flavour. I think there are basically two possibilities, once 'the_package', emacsen-common and an emacsen are unpacked: a) If emacsen-common emacsen are configured first, the lisp files for that package will be byte-compiled twice, once by the emacsen postinst and once again by the package postinst b) If the_package is configured first, nothing will be byte compiled from its postinst, but everything will be byte compiled at emacsen postinst (since emacsen depend on emacsen-common, emacsen-common is already configured when emacsen postinst is run). Well, this looks even good, seems that we are saving one byte-compile run for 'the_package'. All this looks too nice, am I missing something? -- Agustin
Re: search-citeseer_0.1-1_i386.changes REJECTED
Scripsit Agustin Martin Domingo [EMAIL PROTECTED] Last time I read about that, if is byte compiled it should depend on virtual package 'emacsen' (provided by all emacs flavours), since otherwise emacs-package-install failed if no emacsen was installed. If that is true, shouldn't it be counsidered a bug in emacsen-common? I think it ought to be perfectly acceptable to have some large package that, beside its main contents, provides some elisp files that help using the main contents from emacs. If the elisp files are sufficiently large (yet not large enough to justify being spilt out as a separate package), it might still be desirable to byte-compile them. The large package should then depend on emacsen-common, which just provides the infrastructure for scheduling byte-code compilation done at the right time. A user might install the large package without an actual emacsen, but if he later added an emacs, the elisp interfaces would be byte-compiled automatically. Emacs-policy does say D) Each add-on package must declare relevant dependencies on other packages (including other add-on packages). Note that add-on packages should not depend on emacsen-common directly, but rather on either the virtual package emacsen (see below), or some appropriate combination of flavors (i.e. Depends: emacs21 | emacs10). but this, at least understood literally, applies only to *add-on* package consisting largely of elisp code. In that case, just depending on emacsen-common instead of emacsen would be wrong, as policy says: The `Depends' field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. However, when the elisp helper modules in a package is not a significant amount of its functionality, the package ought to be able to register those without depending on an entire emacsen. If emacs-package-install does not support that, it is IMHO a shortcoming of emacs-package-install. You can try a workaround like this if [ $1 = configure -a -x \ /usr/lib/emacsen-common/emacs-package-install ] This wouldn't work - if the package was installed before emacsen-common, its files would never be byte-compiled even if emacs was later added to the system. (And there's no telling whether things would break horribly if emacsen-common happened to be unpacked but not yet configured when the postinst script runs). -- Henning Makholm We're trying to get it into the parts per billion range, but no luck still.
Re: search-citeseer_0.1-1_i386.changes REJECTED
On Fri, Oct 17, 2003 at 12:22:33PM +0200, Wouter Verhelst wrote: James is ftp-master, DAM, autobuilder admin, and part of the debian-admin team as well. Wow! -- gram signature.asc Description: Digital signature
Re: search-citeseer_0.1-1_i386.changes REJECTED
On Thu, Oct 16, 2003 at 08:48:03PM -0300, Otavio Salvador wrote: Peter Makholm [EMAIL PROTECTED] writes: And you still havn't told us what you didn't understand when James wrote: 'If depending on emacs bothers you, make it a suggests.' They *don't* have to have emacs installed! The way of James contact the developpers. He should be more cordial and try explain that things not only reject a package and make conditions to accept this. I understand the cause and how James solve the problem but the thread was more to try take attention on the way of things occour in Debian. We should try be more cordial each other. I'm hardly the sort likely to be first in line to defend Mr. Troup's policies about various things - a causal search of the list archives should make that abundantly clear - but I fail to see how he wasn't being quite civil, polite, and reasonable about it. For that matter, he and I have differed over things in some of my packages; however, he does, in my experience, actually try to explain what the issue is, and offer alternatives if there appear to be any. Listing specific things that must be done before the package will be accepted can, in some cases, sound much less polite - and more like an ultimatum. Listing the reasons for the rejection, and a brief explanation of why they're relevant, should really suffice to give you the opportunity to say I don't agree, here's why: in an equally polite manner. He's been known to change his mind, when presented with suitable evidence or persuasive argument, but his job as ftpmaster is, in large part, to do exactly what he did - reject package uploads that appear to have significant problems, which can include poor packaging decisions. -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpZVMT5Rjc1G.pgp Description: PGP signature
Re: search-citeseer_0.1-1_i386.changes REJECTED
* Otavio Salvador [EMAIL PROTECTED] [2003-10-16 20:44]: Yes. This way to show issues is the right one but the James way is not. He doesn't do a suggestion but an exigency. This is wrong. I've seen package being rejected with a reason plus a note saying something like but if you don't agree with me, please re-upload. In your case, rejecting your package was the right thing; I don't see much reason for any argument or discussion in this particular case, since it's quite clear (as this thread has shown). I'm glad that there are some people who control uploads; infact, I wish they sometimes were stricter (*grumble about animals-games being accepted which I raised an objection when the ITP was posted*). -- Martin Michlmayr [EMAIL PROTECTED]
Re: search-citeseer_0.1-1_i386.changes REJECTED
Am 16.10.03 um 20:44:01 schrieb Otavio Salvador: Steve Greenland [EMAIL PROTECTED] writes: [6 lines of explanation] Yes. This way to show issues is the right one but the James way is not. He doesn't do a suggestion but an exigency. This is wrong. Oh, so you expect a very long and detailed answer to your own little problems? What else do you expect other people to do for you? Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: search-citeseer_0.1-1_i386.changes REJECTED
* Peter S Galbraith | AFAIK, you need to depend on emacs itself (and not emacs-common) if you | byte-compile it. I _think_ stuff can break if you don't, but I'm vague | on why. Search the debian-emacsen archives. I split off a package | because of that issue a while back, but the seperate -el package is 62KB. I don't think you need to, because of the way emacsen have their post-inst-hooks where all the packages which can be used with them are byte-compiled. And as you write below, byte-compiling a 4k file is probably not worth the effort. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: search-citeseer_0.1-1_i386.changes REJECTED
Op vr 17-10-2003, om 01:52 schreef Otavio Salvador: Matthew Palmer [EMAIL PROTECTED] writes: Of course but I think if the developper did something is because he think this is better and this should be respected (if doesn't broke the policy) You've had about 8 people tell you that what you did was a bad idea, along with some pretty reasoned arguments why. (Make mine no. 9 - for all the reasons already mentioned). When public opinion comes out overwhelmingly against you, it's usually time to think hmm, I may be wrong there rather than everybody else is stupid. Yes... I was wrong but my problem is with the way of ftp-master conduct that things. This is the real problem. I wonder why James is receiving such a huge amount of critique these days. James is ftp-master, DAM, autobuilder admin, and part of the debian-admin team as well. He does the things he does the way he does them not because he doesn't like you, but because that's the most efficient use of his time. He doesn't have time to explain the nitty-gritty details of each and every decision he makes. Above all, he's got the most important property for any sysadmin: 'a reasonable amount of paranoia'. That might mean that at times he won't trust some of us, but I think that's a good thing, not a bad one. His only downside is that he's not so communicative, but hey, nobody's perfect. Some might say he's a dictator. I say he happens to be the one who gets the job done -- and I'm sure it's a hell of a job, too. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: search-citeseer_0.1-1_i386.changes REJECTED
Peter S Galbraith [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] wrote: [ I'm including the debian-devel list in CC since I appreciate the opinion of others developpers ] James Troup [EMAIL PROTECTED] writes: This package is dubiously small enough as it is without being split into two. There's no need to separate the 2k .el file into a separate package. If depending on emacs bothers you, make it a suggests. Yes, the packages is small *but* IMHO this should be splited in two since the -el package can but not used. Other issue is the last depends of emacsen and someone can doesn't like have an emacsen installed in machine. -rw-r--r--1 otavio otavio 4.1K Oct 4 16:58 search-citeseer-el_0.1-1_all.deb Are you byte-compiling this elisp? AFAIK, you need to depend on emacs itself (and not emacs-common) if you byte-compile it. I _think_ stuff can break if you don't, but I'm vague on why. Search the debian-emacsen archives. I split off a package because of that issue a while back, but the seperate -el package is 62KB. Yes. I'm byte-compiling this. If the above is correct, then you may bundle your .el file with the main package without depending on Emacs providing that you don't bye-compile it. If it's 4K, it's presumably a very small elisp file anyway. Yes, is small but I've tried to do the most right package project (but a bad decision cause the size of files). -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Tollef Fog Heen [EMAIL PROTECTED] wrote: * Peter S Galbraith | AFAIK, you need to depend on emacs itself (and not emacs-common) if you | byte-compile it. I _think_ stuff can break if you don't, but I'm vague | on why. Search the debian-emacsen archives. I split off a package | because of that issue a while back, but the seperate -el package is 62KB. I don't think you need to, because of the way emacsen have their post-inst-hooks where all the packages which can be used with them are byte-compiled. I found it: http://lists.debian.org/debian-emacsen/2002/debian-emacsen-200202/msg00041.html http://lists.debian.org/debian-emacsen/2002/debian-emacsen-200202/msg00050.html and: http://www.debian.org/doc/packaging-manuals/debian-emacs-policy D) Each add-on package must declare relevant dependencies on other packages (including other add-on packages). Note that add-on packages should not depend on emacsen-common directly, but rather on either the virtual package emacsen (see below), or some appropriate combination of flavors (i.e. Depends: emacs21 | emacs10). And as you write below, byte-compiling a 4k file is probably not worth the effort. That's what I think anyway. Peter
Re: search-citeseer_0.1-1_i386.changes REJECTED
Peter S Galbraith wrote: AFAIK, you need to depend on emacs itself (and not emacs-common) if you byte-compile it. I _think_ stuff can break if you don't, but I'm vague on why. Search the debian-emacsen archives. I split off a package because of that issue a while back, but the seperate -el package is 62KB. Last time I read about that, if is byte compiled it should depend on virtual package 'emacsen' (provided by all emacs flavours), since otherwise emacs-package-install failed if no emacsen was installed. You can try a workaround like this (realign broken lines as appropiate, they are really long) if [ $1 = configure -a -x /usr/lib/emacsen-common/emacs-package-install ] then [ -e /var/lib/emacsen-common/installed-flavors ] \ /usr/lib/emacsen-common/emacs-package-install your_package fi but if Otavio's lisp file is small this is probably an overkill. And Otavio, count me as another one that thinks that having a separate package for such an small lisp file does not worth at all. -- Agustin
Re: search-citeseer_0.1-1_i386.changes REJECTED
On Thu, Oct 16, 2003 at 08:44:01PM -0300, Otavio Salvador wrote: Yes. This way to show issues is the right one but the James way is not. He doesn't do a suggestion but an exigency. This is wrong. He did the right thing. Yes. The reson of my first mail is exactly this. I want make some troube to warn the way of some Debian Developpers do their work. James have the better itention possible, to have small subset possible of packages and like but the way of request it is wrong. James should be more cordial and try talk with developpers. We (developpers) are all tring to do a great distribution and we should always discuss that things and doesn't thing we are always right. The best approach is to bring the subject up for discussion on -devel or -mentors and ask other developers for their input before uploading, splitting, etc. So yes, there should be discussion, but no, it is not his responsibility to initiate discussion, but the maintainer's (yours). -- - mdz
Re: search-citeseer_0.1-1_i386.changes REJECTED
On Thu, Oct 16, 2003 at 05:32:11PM -0300, Otavio Salvador wrote: Joerg Jaspert [EMAIL PROTECTED] writes: Policy is not everything that counts. Just because policy doesnt say something it means it is good to do it. Of course but I think if the developper did something is because he think this is better and this should be respected (if doesn't broke the policy) Respected, certainly. Accepted without question? Certainly not. More or less. Doesn't make sense include a depends of Emacs in search-citeseer and the -el part depends of this. The better option is split in two package each with your depends and needs. The sugestion of James is not right to include emacs like a suggets is not good since the package need emacsen to work. This is exactly what Recommends and Suggests are for. -- - mdz
Re: search-citeseer_0.1-1_i386.changes REJECTED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [ I'm including the debian-devel list in CC since I appreciate the opinion of others developpers ] James Troup [EMAIL PROTECTED] writes: This package is dubiously small enough as it is without being split into two. There's no need to separate the 2k .el file into a separate package. If depending on emacs bothers you, make it a suggests. Yes, the packages is small *but* IMHO this should be splited in two since the -el package can but not used. Other issue is the last depends of emacsen and someone can doesn't like have an emacsen installed in machine. - -rw-r--r--1 otavio otavio 4.1K Oct 4 16:58 search-citeseer-el_0.1-1_all.deb - -rw-r--r--1 otavio otavio 2.9K Oct 4 16:58 search-citeseer_0.1-1.diff.gz - -rw-r--r--1 otavio otavio610 Oct 4 16:58 search-citeseer_0.1-1.dsc - -rw-r--r--1 otavio otavio 5.4K Oct 4 16:58 search-citeseer_0.1-1_all.deb - -rw-r--r--1 otavio otavio 1.2K Oct 4 16:58 search-citeseer_0.1-1_i386.changes - -rw-r--r--1 otavio otavio11K Oct 4 16:56 search-citeseer_0.1.orig.tar.gz I think the current package is ready for inclusion in Debian Project and really like if you reconsider your decision. If we doesn't want small packages in Debian, please include this in Debian Policy and then I'll agree without asking but this is not the case. Thanks in Advance, Otavio - -- O T A V I OS A L V A D O R - - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQE/jr5JLqiZQEml+FURAvjGAJ9FbITI7GzMxfTnUmouMSaqdBRNPgCaA9+C QJY4l0fdmRS/lKn1tNhwf18= =vmyL -END PGP SIGNATURE-
Re: search-citeseer_0.1-1_i386.changes REJECTED
On 16-Oct-03, 10:50 (CDT), Otavio Salvador [EMAIL PROTECTED] wrote: [ I'm including the debian-devel list in CC since I appreciate the opinion of others developpers ] Okay, since you ask: James Troup [EMAIL PROTECTED] writes: This package is dubiously small enough as it is without being split into two. There's no need to separate the 2k .el file into a separate package. If depending on emacs bothers you, make it a suggests. James is correct. Just put it all in one package. No one is obliged to use the .el files. Other issue is the last depends of emacsen and someone can doesn't like have an emacsen installed in machine. What part of If depending on emacs bothers you, make it a suggests. did you not understand? If we doesn't want small packages in Debian, please include this in Debian Policy and then I'll agree without asking but this is not the case. Not every good practice is in Policy. You're supposed to be able to apply a little common sense as well. The objection is not to a small package but pointless splitting of packages. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador [EMAIL PROTECTED] wrote: [ I'm including the debian-devel list in CC since I appreciate the opinion of others developpers ] James Troup [EMAIL PROTECTED] writes: This package is dubiously small enough as it is without being split into two. There's no need to separate the 2k .el file into a separate package. If depending on emacs bothers you, make it a suggests. Yes, the packages is small *but* IMHO this should be splited in two since the -el package can but not used. Other issue is the last depends of emacsen and someone can doesn't like have an emacsen installed in machine. [...] If that bothers you, make it a suggests instead of a depends. What point am I missing? cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: search-citeseer_0.1-1_i386.changes REJECTED
Steve Greenland [EMAIL PROTECTED] writes: On 16-Oct-03, 10:50 (CDT), Otavio Salvador [EMAIL PROTECTED] wrote: [ I'm including the debian-devel list in CC since I appreciate the opinion of others developpers ] Okay, since you ask: Perfect :-) James Troup [EMAIL PROTECTED] writes: This package is dubiously small enough as it is without being split into two. There's no need to separate the 2k .el file into a separate package. If depending on emacs bothers you, make it a suggests. James is correct. Just put it all in one package. No one is obliged to use the .el files. And no one is obliged to do all like James think. The package follow the policy and doesn't have any point in policy talking about size requeriments. Other issue is the last depends of emacsen and someone can doesn't like have an emacsen installed in machine. What part of If depending on emacs bothers you, make it a suggests. did you not understand? Yes, I understand but is not right to me. Is really more logical split it in two packages. If enduser need the emacs interface, only install the -el. If we doesn't want small packages in Debian, please include this in Debian Policy and then I'll agree without asking but this is not the case. Not every good practice is in Policy. You're supposed to be able to apply a little common sense as well. The objection is not to a small package but pointless splitting of packages. Yes but to my sense is really better to enduser have this packages splited since the search-citeseer can work (without problems) without the -el part and I want provide this option for our users. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Andreas Metzler [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] wrote: [ I'm including the debian-devel list in CC since I appreciate the opinion of others developpers ] James Troup [EMAIL PROTECTED] writes: This package is dubiously small enough as it is without being split into two. There's no need to separate the 2k .el file into a separate package. If depending on emacs bothers you, make it a suggests. Yes, the packages is small *but* IMHO this should be splited in two since the -el package can but not used. Other issue is the last depends of emacsen and someone can doesn't like have an emacsen installed in machine. [...] If that bothers you, make it a suggests instead of a depends. What point am I missing? The opinion of James is not the same of my. I doesn't want to do all thinks like he want but yes like the policy and major of users say. The Social Contract say: The focus is the user. So, to enduser is more easy provide two packages and he can choice what to do. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador [EMAIL PROTECTED] writes: And no one is obliged to do all like James think. The package follow the policy and doesn't have any point in policy talking about size requeriments. Policy is not everything that counts. Just because policy doesnt say something it means it is good to do it. Its a useless split, not needed and there is no benefit for the users. One can say its against users - everyone that wants .el files needs to install another package. :) Yes but to my sense is really better to enduser have this packages splited since the search-citeseer can work (without problems) without the -el part and I want provide this option for our users. It can work without is not enough for a split. One reason, but not everything. If we would split everything that works without the rest in the package we would end up with thousands of useless small packages. We already have enough packages in the list, we dont need things there we can avoid without problems. -- bye Joerg elmo if klecker.d.o died, I swear to god, I'm going to migrate to gentoo. pgp3iOWpoz7cI.pgp Description: PGP signature
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador [EMAIL PROTECTED] writes: The Social Contract say: The focus is the user. So, to enduser is more easy provide two packages and he can choice what to do. I disagree. Forcing the user to spend to much time micromanage which stuff he wants is not to the bennefit of the user. Neither for the unexperienced user nor the power user. It is bad practise to split packages just because it is posible to use some parts of the package. -- Peter Makholm | If you can't do any damage as root, are you still [EMAIL PROTECTED] | really root? http://hacking.dk | -- Derek Gladding about SELinux
Re: search-citeseer_0.1-1_i386.changes REJECTED
On 16-Oct-03, 13:11 (CDT), Otavio Salvador [EMAIL PROTECTED] wrote: Yes but to my sense is really better to enduser have this packages splited since the search-citeseer can work (without problems) without the -el part and I want provide this option for our users. My sense is exactly the opposite: people who don't use the -el will not be inconvenienced by a few Kb of extra files, but those who want them will have to go through extra effort to get them, after figuring out why part of the upstream package is missing. And _everyone_ will have a fractionally larger Packages file to download, and yet another package item in whatever browser tool they use, cluttering searches. And forget the It's not in Policy argument. Policy doesn't say don't put 'rm -rf /' in the postinst either, but that doesn't make it a good thing to do. Policy doesn't say The minimum package size is N bytes, because that doesn't make any sense - a package is as big as it needs to be. Policy is intended to be a minimal document, the least that we need to regulate to make a coherent integrated system. Glancing at a even few of the core packages should convince you that it is not general practice to split upstream packages into the smallest possible subsets. Everyone who has replied to your question (as of this writing) has said it's a bad idea to split a package this small. If you honestly wanted our opinions, this consistent response should be enough to make you reconsider. If you were expecting a universal Oh, that evil James Troup, he's a power mad dictator response, well, sorry, that's a different thread, and a different topic. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: search-citeseer_0.1-1_i386.changes REJECTED
Joerg Jaspert [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] writes: And no one is obliged to do all like James think. The package follow the policy and doesn't have any point in policy talking about size requeriments. Policy is not everything that counts. Just because policy doesnt say something it means it is good to do it. Of course but I think if the developper did something is because he think this is better and this should be respected (if doesn't broke the policy) Its a useless split, not needed and there is no benefit for the users. One can say its against users - everyone that wants .el files needs to install another package. :) Yes but to my sense is really better to enduser have this packages splited since the search-citeseer can work (without problems) without the -el part and I want provide this option for our users. It can work without is not enough for a split. One reason, but not everything. If we would split everything that works without the rest in the package we would end up with thousands of useless small packages. We already have enough packages in the list, we dont need things there we can avoid without problems. More or less. Doesn't make sense include a depends of Emacs in search-citeseer and the -el part depends of this. The better option is split in two package each with your depends and needs. The sugestion of James is not right to include emacs like a suggets is not good since the package need emacsen to work. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Peter Makholm [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] writes: The Social Contract say: The focus is the user. So, to enduser is more easy provide two packages and he can choice what to do. I disagree. Forcing the user to spend to much time micromanage which stuff he wants is not to the bennefit of the user. Neither for the unexperienced user nor the power user. More or less. One search show both packages and user can read what each do. Not so dificult ;-) It is bad practise to split packages just because it is posible to use some parts of the package. Of course. But one dependence like Emacs is. Many users doesn't want emacs installed and they should be respected. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador [EMAIL PROTECTED] writes: I disagree. Forcing the user to spend to much time micromanage which stuff he wants is not to the bennefit of the user. Neither for the unexperienced user nor the power user. More or less. One search show both packages and user can read what each do. Not so dificult ;-) Not if you're the only one splitting packages unneccesary then it doensn't matter. But you're not the only developer. Unneccessary package splits isn't a problem if they only happends for a single package but on a larger scale the means problems. Micromanagement is bad! It is bad practise to split packages just because it is posible to use some parts of the package. Of course. But one dependence like Emacs is. Many users doesn't want emacs installed and they should be respected. And you still havn't told us what you didn't understand when James wrote: 'If depending on emacs bothers you, make it a suggests.' They *don't* have to have emacs installed! -- Peter Makholm | Why does the entertainment industry wants us to [EMAIL PROTECTED] | believe that a society base on full surveillance http://hacking.dk | is bad? | Do they have something to hide?
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador [EMAIL PROTECTED] writes: More or less. Doesn't make sense include a depends of Emacs in search-citeseer and the -el part depends of this. The better option is split in two package each with your depends and needs. No. The sugestion of James is not right to include emacs like a suggets is not good since the package need emacsen to work. For this package the suggest is enough. People that want to use the -el files have emacs installed. Or they dont want to use the -el files. :) The suggest is more like a reminder that there is something you can do in emacs with this package imo. -- bye Joerg Das Ding heißt zwar Laptop, aber das sollte man so wörtlich nicht nehmen. Ein 50-jähriger schwedischer Wissenschaftler zog sich Verbrennungen an den Geschlechtsteilen zu, weil er das Ding bei der Arbeit auf dem Schoß hielt. pgp2N9CJ4yGYH.pgp Description: PGP signature
Re: search-citeseer_0.1-1_i386.changes REJECTED
On Thu, Oct 16, 2003 at 05:32:11PM -0300, Otavio Salvador wrote: Joerg Jaspert [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] writes: And no one is obliged to do all like James think. The package follow the policy and doesn't have any point in policy talking about size requeriments. Policy is not everything that counts. Just because policy doesnt say something it means it is good to do it. Of course but I think if the developper did something is because he think this is better and this should be respected (if doesn't broke the policy) You've had about 8 people tell you that what you did was a bad idea, along with some pretty reasoned arguments why. (Make mine no. 9 - for all the reasons already mentioned). When public opinion comes out overwhelmingly against you, it's usually time to think hmm, I may be wrong there rather than everybody else is stupid. It can work without is not enough for a split. One reason, but not everything. If we would split everything that works without the rest in the package we would end up with thousands of useless small packages. We already have enough packages in the list, we dont need things there we can avoid without problems. More or less. Doesn't make sense include a depends of Emacs in search-citeseer and the -el part depends of this. The better option is split in two package each with your depends and needs. Extending your argument just a bit, then there'd be a Debian package for every binary, along with a bunch more for the collections of files all those binaries need to work. It Just Won't Scale. The sugestion of James is not right to include emacs like a suggets is not good since the package need emacsen to work. And the only people who will give a crap about the -el working are those who have emacs. Presumably installed, so they won't notice that it needs emacs to work. I truly believe it's time to cut your losses, swallow your pride, and move on. Unless the lurkers support you in e-mail, of course. - Matt
Re: search-citeseer_0.1-1_i386.changes REJECTED
Steve Greenland [EMAIL PROTECTED] writes: On 16-Oct-03, 13:11 (CDT), Otavio Salvador [EMAIL PROTECTED] wrote: Yes but to my sense is really better to enduser have this packages splited since the search-citeseer can work (without problems) without the -el part and I want provide this option for our users. My sense is exactly the opposite: people who don't use the -el will not be inconvenienced by a few Kb of extra files, but those who want them will have to go through extra effort to get them, after figuring out why part of the upstream package is missing. And _everyone_ will have a fractionally larger Packages file to download, and yet another package item in whatever browser tool they use, cluttering searches. Yes. This way to show issues is the right one but the James way is not. He doesn't do a suggestion but an exigency. This is wrong. And forget the It's not in Policy argument. Policy doesn't say don't put 'rm -rf /' in the postinst either, but that doesn't make it a good thing to do. Policy doesn't say The minimum package size is N bytes, because that doesn't make any sense - a package is as big as it needs to be. Policy is intended to be a minimal document, the least that we need to regulate to make a coherent integrated system. Yes but policy also include what we have don't do. Glancing at a even few of the core packages should convince you that it is not general practice to split upstream packages into the smallest possible subsets. Everyone who has replied to your question (as of this writing) has said it's a bad idea to split a package this small. If you honestly wanted our opinions, this consistent response should be enough to make you reconsider. If you were expecting a universal Oh, that evil James Troup, he's a power mad dictator response, well, sorry, that's a different thread, and a different topic. Yes. The reson of my first mail is exactly this. I want make some troube to warn the way of some Debian Developpers do their work. James have the better itention possible, to have small subset possible of packages and like but the way of request it is wrong. James should be more cordial and try talk with developpers. We (developpers) are all tring to do a great distribution and we should always discuss that things and doesn't thing we are always right. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Peter Makholm [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] writes: I disagree. Forcing the user to spend to much time micromanage which stuff he wants is not to the bennefit of the user. Neither for the unexperienced user nor the power user. More or less. One search show both packages and user can read what each do. Not so dificult ;-) Not if you're the only one splitting packages unneccesary then it doensn't matter. But you're not the only developer. Unneccessary package splits isn't a problem if they only happends for a single package but on a larger scale the means problems. Micromanagement is bad! Sure. It is bad practise to split packages just because it is posible to use some parts of the package. Of course. But one dependence like Emacs is. Many users doesn't want emacs installed and they should be respected. And you still havn't told us what you didn't understand when James wrote: 'If depending on emacs bothers you, make it a suggests.' They *don't* have to have emacs installed! The way of James contact the developpers. He should be more cordial and try explain that things not only reject a package and make conditions to accept this. I understand the cause and how James solve the problem but the thread was more to try take attention on the way of things occour in Debian. We should try be more cordial each other. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Matthew Palmer [EMAIL PROTECTED] writes: Of course but I think if the developper did something is because he think this is better and this should be respected (if doesn't broke the policy) You've had about 8 people tell you that what you did was a bad idea, along with some pretty reasoned arguments why. (Make mine no. 9 - for all the reasons already mentioned). When public opinion comes out overwhelmingly against you, it's usually time to think hmm, I may be wrong there rather than everybody else is stupid. Yes... I was wrong but my problem is with the way of ftp-master conduct that things. This is the real problem. The sugestion of James is not right to include emacs like a suggets is not good since the package need emacsen to work. And the only people who will give a crap about the -el working are those who have emacs. Presumably installed, so they won't notice that it needs emacs to work. I truly believe it's time to cut your losses, swallow your pride, and move on. Unless the lurkers support you in e-mail, of course. Yes. This discussion was very useful to me learn some things and see some others. But the focus of my problem was not the package reject but the way ;-) Only it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: search-citeseer_0.1-1_i386.changes REJECTED
Otavio Salvador [EMAIL PROTECTED] wrote: [ I'm including the debian-devel list in CC since I appreciate the opinion of others developpers ] James Troup [EMAIL PROTECTED] writes: This package is dubiously small enough as it is without being split into two. There's no need to separate the 2k .el file into a separate package. If depending on emacs bothers you, make it a suggests. Yes, the packages is small *but* IMHO this should be splited in two since the -el package can but not used. Other issue is the last depends of emacsen and someone can doesn't like have an emacsen installed in machine. -rw-r--r--1 otavio otavio 4.1K Oct 4 16:58 search-citeseer-el_0.1-1_all.deb Are you byte-compiling this elisp? AFAIK, you need to depend on emacs itself (and not emacs-common) if you byte-compile it. I _think_ stuff can break if you don't, but I'm vague on why. Search the debian-emacsen archives. I split off a package because of that issue a while back, but the seperate -el package is 62KB. If the above is correct, then you may bundle your .el file with the main package without depending on Emacs providing that you don't bye-compile it. If it's 4K, it's presumably a very small elisp file anyway. Peter
