Bootsplash Updates
Some time tommorrow (aka in the morning/afternoon) I should release updated (and IMO improved) versons of my bootsplash packages. I have moved some stuff around and added some config options. Right now the only thing keeping me from uploading these packages to mentors.debian.net are licence clarifications. The bootsplash-theme-matrix and bootsplash-theme-tuxntosh packages currently do not have a licence, I am in the process of contacting the original developer and clearling this up. If I cannot contact him I will not upload any new versions of these packages (unless someone has a better solution (im sure someone does)). Also I have changed the name of the bootsplash-theme-debiantux package to bootsplash-theme-debian-tux and inorder for it to install correctly you must first remove the bootsplash-theme-debiantux package (it should be removed when installing the new package, but I had problems with this). Let me know if ya have any problems. -- Matthew A. Nicholson Matt-Land.com
Re: RFS: ike-scan
Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : > Hi Benoit, > > > i just uploaded ike-scan 1.5.1 to mentors.debian.net and i'am looking > > for a sponsor. > > > > The package is lintian and linda clean, here is the control file > > - you should provide the file downloaded from > http://www.nta-monitor.com/ike-scan/ as ike-scan_1.5.1.orig.tar.gz. ok done it > - you ship an empty /usr/sbin directory. Please remove from debian/dirs thanks removed > - your Standards-Version is ancient. bumped to 3.6.0 > - do you really need to link /usr/share/doc/ike-scan to /usr/doc? > If not, you might remove the postinst and prerm scripts. thats what lintian wanted but linda not so i removed it > The package itself compiles OK, even on Alpha and recognized > FreeBSD/OpenBSD-isakmpd and FreeBSD-racoon (both running on Linux) OK for > me :-) glad to hear it ;-) I have just uploaded a new package to mentors.debian.net Could you check it ? Thanks -- OpenSides sprl Free Software Specialist Benoit Mortier - Linux Engineer pgppJnWuqQtem.pgp Description: signature
Re: RFS: ike-scan
On 30.12.03 12:12 Benoit Mortier wrote: Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : [...] - do you really need to link /usr/share/doc/ike-scan to /usr/doc? If not, you might remove the postinst and prerm scripts. thats what lintian wanted but linda not so i removed it You should upgrade you version of lintian. A not completely outdated version of lind (i.e. the version in sid or sarge) should not "want" the /usr/doc/ symlink but should issue a warning if it exists. cu andreas
RFS : sipcalc -- Advanced console-based ip subnet calculator
Hello, I packaged [1] sipcalc [2] and I'm looking for a sponsor for the package. I already have the dnstop package in Debian. Sipcalc is lintian and linda clean and available for review [3]. Bernhard, I am cc-ing this to you, because you sponsor my dnstop package. --- Sipcalc is an advanced console-based IP subnet calculator. It can take multiple forms of input (IPv4/IPv6/interface/hostname) and output a multitude of information about a given subnet. As opposed to ipv6calc, all output can be generated using a single command and thus requires less knowdledge of the different command line options. --- Thanks, Adriaan Peeters [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225509 [2] http://www.routemeister.net/projects/sipcalc/ [3] http://dev.lashout.net/debian/
RFS: eli, eli-doc -- compiler construction kit (and documentation)
Hi. I just wanted to ask again for a sponsor for for eli. Packages are available at: deb http://www.lichtenheld.de/debian ./ deb-src http://www.lichtenheld.de/debian ./ I've also attached the changelog for eli which is already rather long since I'm maintaining this package locally for over a year now. ITP bug is #68262. I'm in the NM queue and maintain two other packages in Debian. Descriptions: eli: compiler construction kit Eli provides modern compiler construction facilities to users with a wide range of sophistication. It offers complete solutions for commonly-encountered language implementation subtasks and contains libraries of reusable specifications, making possible the production of high-quality implementations from simple problem descriptions. odin (built from same source): powerful make replacement Odin is a build manager like make with some important differences: * derived files are stored in a central cache * dependency and timstamp information are collected and stored automatically . This avoids some of the major problems of make: Different and/or parallel builds from the same source tree, time skew problems, and dependency control. . This package contains version 1.17.4 of odin with some additional patches and is built from the Eli source (see eli package). eli-doc (separate source package): HTML and PostScript documentation for eli The eli package contains extensive documentation in the Texinfo format. This package provides the same documentation in alternative formats (HTML and PostScript). Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ pgpcDAfTmKCZZ.pgp Description: PGP signature
Re: RFS: ike-scan
Le Mardi 30 Décembre 2003 14:20, Andreas Metzler a écrit : > On 30.12.03 12:12 Benoit Mortier wrote: > > Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : > > [...] > > >> - do you really need to link /usr/share/doc/ike-scan to /usr/doc? > >> If not, you might remove the postinst and prerm scripts. > > > > thats what lintian wanted but linda not so i removed it > > You should upgrade you version of lintian. A not completely outdated > version of lind (i.e. the version in sid or sarge) should not "want" the > /usr/doc/ symlink but should issue a warning if it exists. This package was first build on my woody box but now is builded inside pbuibler ( was a nice tol ;-) ) and now this is corrected Thanks -- OpenSides sprl Free Software Specialist Benoit Mortier - Linux Engineer pgplJqbaJieJf.pgp Description: signature
debian packages: single diff vs multiple patches (as in rpm)
Although philosophically more aligned with Debian, I had been a RedHat user for almost 8 years largely pragmatic reasons that aren't relevant. As such, I have developed a large rpm-based infrastructure for releasing my company's own software to our production facilities and have become quite familiar with RedHat's rpm system from the developer's perspective. Now I'm strongly considering making the switch to Debian and am evaluating moving my whole installation system over to dpkg. dpkg seems superior to rpm in almost all respects (richer dependencies, better documentation, more robustness, apt, etc.), but there's one thing that bothers me. When building an rpm, multiple source files and multiple patch files can be specified, and arbitrary commands can be used to extract sources and apply patches. This makes it easy to build an rpm of a standard package with a handful of separately maintained patches applied. As far as I can tell, a Debian package consists of a single source tarball and a single diff. Is this right, or have I missed something? Coming from an rpm perspective, it seems to me that this would make it much more difficult to manage locally modified versions of packages. I'd appreciate if someone could either explain to me that I've got it all wrong give me a pointer for what to look like, or confirm that my understanding is correct but explain why this isn't really a problem. I'm especially interested in hearing thoughts from other people who have converted an rpm-based infrastructure to a dpkg-based infrastructure. Lastly, please feel free to correct my terminology if I'm using it incorrectly. For example, is it correct to say dpkg-based rather than deb-based? Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: debian packages: single diff vs multiple patches (as in rpm)
Hi. I suppose you have already found the most generic pointers like new maintainer guide ans such. Jay Berkenbilt wrote: > As far as I can tell, a Debian package consists of a single source > tarball and a single diff. Is this right, or have I missed something? > Coming from an rpm perspective, it seems to me that this would make it > much more difficult to manage locally modified versions of packages. Although patch management is not directly included in dpkg-source it is, naturally, widely used by debian source packages. Almost any of the larger packages apply patches (stored themselves in the diff.gz) during package building, so you have plenty of examples. There also are specialized tools, e.g. dpatch. It is also not uncommon to make an orig.tar.gz of (possibly multiple) upstream tarballs by putting them in a directory and tarring that. As there is a distinct preference to ship pristine upstream tarballs in some form or other, this is preferable than extracting them and tarring the result. (The first package doing this I could think of is sendmail, but there's plenty of other, potentially better examples.) Kind regards Thomas pgpJUqqxFp2VI.pgp Description: PGP signature
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, 30 Dec 2003, Jay Berkenbilt wrote: > As far as I can tell, a Debian package consists of a single source > tarball and a single diff. Is this right, or have I missed something? It's right, a Debian source package is usually distributed as a single source and a single diff (sometimes there is no diff when the package is "debian native"), but nothing prevents you from having several sources and several diffs internally, see the dbs, cdbs and dpatch packages, for example (if you want real usage examples, look for source packages which have those in the Build-Depends).
未承諾広告※5000円で開業 しませんか！
未承諾広告※ ご迷惑な方は削除してください。 当広告を受信拒否の方は次のメールアドレスに〔受信拒否〕 として送信してください。その日のうちに削除いたします。ご迷惑でしょうがよろしくお願いいたします [EMAIL PROTECTED] 販売者 ギフト 所在地 京都府城陽市寺田８−２ 代表者 山本しおり TEL 0774-56-6428 5000円で開業しませんか！！ 世の中不景気がいつまでも続き先が見えない状態です。今大丈夫でも あなたにいつリストラ等の不幸が襲ってくるかわかりません。 また一般庶民が何か事業をやろうと思っても資金面などで容易に 出来るものではありません。 過去を振り返ってみてあの時あれをしておけば良かったとか、あの時自分 にはすごいチャンスがお訪れていたんだなぁとか思うことはありませんか？ その時実行さへしていれば貴方は今頃ある程度の成功者になっていた筈です。 ひよっとすればこの開業パックもその類に入るかもしれません。現代は 情報の時代です。各種情報が満溢ですがたったの５０００円で手に入ります。 この開業パックを売るもよし（一枚売れば元は取れます）保存版にして楽しむ むのもよし貴方の好きな様に使ってください。 実際に販売してみるとビックリするほど売れます。たったの５０００円 で貴方は将来の不安から解放されそのうえ勝ち組の一人になれる筈です。 それでは健闘を期待します。頑張ってください！！今の状態から脱出しましょう！！ 百聞は一見に如かず,5000円で開業してみませんか!! http://dreamhand.cjb.net/
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 05:56:33PM +0100, Thomas Viehmann <[EMAIL PROTECTED]> wrote: > It is also not uncommon to make an orig.tar.gz of (possibly multiple) > upstream tarballs by putting them in a directory and tarring that. Ofcourse you mean tar+gzip that, as orig is always tar.gz; alhough I think it's quite unefficient to have upstream source in tar.bz2 in some dir, and tar.gz it into orig.tar.gz ... Sometimes I feel that it would be better to utilize source mirrors. I mean Debian ftp servers would carry the diff.gz+dsc files, but not the package source (orig.tar.gz) - instead a mirror list for that source should be maintained, and automagically downloaded by 'apt-get source' from the first available. Cheers, GCS
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 11:06:35AM -0500, Jay Berkenbilt wrote: > Now I'm strongly considering making the switch to Debian and am > evaluating moving my whole installation system over to dpkg. dpkg > seems superior to rpm in almost all respects (richer dependencies, > better documentation, more robustness, apt, etc.), but there's one > thing that bothers me. When building an rpm, multiple source files > and multiple patch files can be specified, and arbitrary commands can > be used to extract sources and apply patches. This makes it easy to > build an rpm of a standard package with a handful of separately > maintained patches applied. While multiple patches are certainly advantageous (and are, I believe, intended to be supported in the next version of the Debian source package format), I don't like the idea of arbitrary commands to extract sources and apply patches. I very much prefer being able to unpack and examine the source of a package without trusting the person who created it. There are various systems used in Debian which pack multiple patches into the Debian .diff (see dpatch, cdbs, etc.). > As far as I can tell, a Debian package consists of a single source > tarball and a single diff. Is this right, or have I missed something? > Coming from an rpm perspective, it seems to me that this would make it > much more difficult to manage locally modified versions of packages. I prefer to use CVS (see the cvs-buildpackage package) to maintain local branches of Debian packages. Since CVS doesn't separate patches either, there isn't much lost there. > Lastly, please feel free to correct my terminology if I'm using it > incorrectly. For example, is it correct to say dpkg-based rather than > deb-based? dpkg is a program which operates on Debian packages. "deb" is a common shorthand for the Debian binary package format. -- - mdz
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 08:55:55PM +0100, GCS wrote: > On Tue, Dec 30, 2003 at 05:56:33PM +0100, Thomas Viehmann <[EMAIL PROTECTED]> > wrote: > > It is also not uncommon to make an orig.tar.gz of (possibly multiple) > > upstream tarballs by putting them in a directory and tarring that. > Ofcourse you mean tar+gzip that, as orig is always tar.gz; alhough I > think it's quite unefficient to have upstream source in tar.bz2 in some > dir, and tar.gz it into orig.tar.gz ... Sometimes I feel that it would > be better to utilize source mirrors. I mean Debian ftp servers would > carry the diff.gz+dsc files, but not the package source (orig.tar.gz) - > instead a mirror list for that source should be maintained, and > automagically downloaded by 'apt-get source' from the first available. In addition to unnecessarily complicating what is currently a simple and reliable process, this would violate the licenses of much of the software that Debian distributes. -- - mdz
Bootsplash Updates
Some time tommorrow (aka in the morning/afternoon) I should release updated (and IMO improved) versons of my bootsplash packages. I have moved some stuff around and added some config options. Right now the only thing keeping me from uploading these packages to mentors.debian.net are licence clarifications. The bootsplash-theme-matrix and bootsplash-theme-tuxntosh packages currently do not have a licence, I am in the process of contacting the original developer and clearling this up. If I cannot contact him I will not upload any new versions of these packages (unless someone has a better solution (im sure someone does)). Also I have changed the name of the bootsplash-theme-debiantux package to bootsplash-theme-debian-tux and inorder for it to install correctly you must first remove the bootsplash-theme-debiantux package (it should be removed when installing the new package, but I had problems with this). Let me know if ya have any problems. -- Matthew A. Nicholson Matt-Land.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ike-scan
Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : > Hi Benoit, > > > i just uploaded ike-scan 1.5.1 to mentors.debian.net and i'am looking > > for a sponsor. > > > > The package is lintian and linda clean, here is the control file > > - you should provide the file downloaded from > http://www.nta-monitor.com/ike-scan/ as ike-scan_1.5.1.orig.tar.gz. ok done it > - you ship an empty /usr/sbin directory. Please remove from debian/dirs thanks removed > - your Standards-Version is ancient. bumped to 3.6.0 > - do you really need to link /usr/share/doc/ike-scan to /usr/doc? > If not, you might remove the postinst and prerm scripts. thats what lintian wanted but linda not so i removed it > The package itself compiles OK, even on Alpha and recognized > FreeBSD/OpenBSD-isakmpd and FreeBSD-racoon (both running on Linux) OK for > me :-) glad to hear it ;-) I have just uploaded a new package to mentors.debian.net Could you check it ? Thanks -- OpenSides sprl Free Software Specialist Benoit Mortier - Linux Engineer pgp0.pgp Description: signature
Re: RFS: ike-scan
On 30.12.03 12:12 Benoit Mortier wrote: Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : [...] - do you really need to link /usr/share/doc/ike-scan to /usr/doc? If not, you might remove the postinst and prerm scripts. thats what lintian wanted but linda not so i removed it You should upgrade you version of lintian. A not completely outdated version of lind (i.e. the version in sid or sarge) should not "want" the /usr/doc/ symlink but should issue a warning if it exists. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS : sipcalc -- Advanced console-based ip subnet calculator
Hello, I packaged [1] sipcalc [2] and I'm looking for a sponsor for the package. I already have the dnstop package in Debian. Sipcalc is lintian and linda clean and available for review [3]. Bernhard, I am cc-ing this to you, because you sponsor my dnstop package. --- Sipcalc is an advanced console-based IP subnet calculator. It can take multiple forms of input (IPv4/IPv6/interface/hostname) and output a multitude of information about a given subnet. As opposed to ipv6calc, all output can be generated using a single command and thus requires less knowdledge of the different command line options. --- Thanks, Adriaan Peeters [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225509 [2] http://www.routemeister.net/projects/sipcalc/ [3] http://dev.lashout.net/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: eli, eli-doc -- compiler construction kit (and documentation)
Hi. I just wanted to ask again for a sponsor for for eli. Packages are available at: deb http://www.lichtenheld.de/debian ./ deb-src http://www.lichtenheld.de/debian ./ I've also attached the changelog for eli which is already rather long since I'm maintaining this package locally for over a year now. ITP bug is #68262. I'm in the NM queue and maintain two other packages in Debian. Descriptions: eli: compiler construction kit Eli provides modern compiler construction facilities to users with a wide range of sophistication. It offers complete solutions for commonly-encountered language implementation subtasks and contains libraries of reusable specifications, making possible the production of high-quality implementations from simple problem descriptions. odin (built from same source): powerful make replacement Odin is a build manager like make with some important differences: * derived files are stored in a central cache * dependency and timstamp information are collected and stored automatically . This avoids some of the major problems of make: Different and/or parallel builds from the same source tree, time skew problems, and dependency control. . This package contains version 1.17.4 of odin with some additional patches and is built from the Eli source (see eli package). eli-doc (separate source package): HTML and PostScript documentation for eli The eli package contains extensive documentation in the Texinfo format. This package provides the same documentation in alternative formats (HTML and PostScript). Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ pgp0.pgp Description: PGP signature
Re: RFS: ike-scan
Le Mardi 30 Décembre 2003 14:20, Andreas Metzler a écrit : > On 30.12.03 12:12 Benoit Mortier wrote: > > Le Lundi 29 Décembre 2003 23:54, Jochen Friedrich a écrit : > > [...] > > >> - do you really need to link /usr/share/doc/ike-scan to /usr/doc? > >> If not, you might remove the postinst and prerm scripts. > > > > thats what lintian wanted but linda not so i removed it > > You should upgrade you version of lintian. A not completely outdated > version of lind (i.e. the version in sid or sarge) should not "want" the > /usr/doc/ symlink but should issue a warning if it exists. This package was first build on my woody box but now is builded inside pbuibler ( was a nice tol ;-) ) and now this is corrected Thanks -- OpenSides sprl Free Software Specialist Benoit Mortier - Linux Engineer pgp0.pgp Description: signature
debian packages: single diff vs multiple patches (as in rpm)
Although philosophically more aligned with Debian, I had been a RedHat user for almost 8 years largely pragmatic reasons that aren't relevant. As such, I have developed a large rpm-based infrastructure for releasing my company's own software to our production facilities and have become quite familiar with RedHat's rpm system from the developer's perspective. Now I'm strongly considering making the switch to Debian and am evaluating moving my whole installation system over to dpkg. dpkg seems superior to rpm in almost all respects (richer dependencies, better documentation, more robustness, apt, etc.), but there's one thing that bothers me. When building an rpm, multiple source files and multiple patch files can be specified, and arbitrary commands can be used to extract sources and apply patches. This makes it easy to build an rpm of a standard package with a handful of separately maintained patches applied. As far as I can tell, a Debian package consists of a single source tarball and a single diff. Is this right, or have I missed something? Coming from an rpm perspective, it seems to me that this would make it much more difficult to manage locally modified versions of packages. I'd appreciate if someone could either explain to me that I've got it all wrong give me a pointer for what to look like, or confirm that my understanding is correct but explain why this isn't really a problem. I'm especially interested in hearing thoughts from other people who have converted an rpm-based infrastructure to a dpkg-based infrastructure. Lastly, please feel free to correct my terminology if I'm using it incorrectly. For example, is it correct to say dpkg-based rather than deb-based? Thanks! -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian packages: single diff vs multiple patches (as in rpm)
Hi. I suppose you have already found the most generic pointers like new maintainer guide ans such. Jay Berkenbilt wrote: > As far as I can tell, a Debian package consists of a single source > tarball and a single diff. Is this right, or have I missed something? > Coming from an rpm perspective, it seems to me that this would make it > much more difficult to manage locally modified versions of packages. Although patch management is not directly included in dpkg-source it is, naturally, widely used by debian source packages. Almost any of the larger packages apply patches (stored themselves in the diff.gz) during package building, so you have plenty of examples. There also are specialized tools, e.g. dpatch. It is also not uncommon to make an orig.tar.gz of (possibly multiple) upstream tarballs by putting them in a directory and tarring that. As there is a distinct preference to ship pristine upstream tarballs in some form or other, this is preferable than extracting them and tarring the result. (The first package doing this I could think of is sendmail, but there's plenty of other, potentially better examples.) Kind regards Thomas pgp0.pgp Description: PGP signature
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, 30 Dec 2003, Jay Berkenbilt wrote: > As far as I can tell, a Debian package consists of a single source > tarball and a single diff. Is this right, or have I missed something? It's right, a Debian source package is usually distributed as a single source and a single diff (sometimes there is no diff when the package is "debian native"), but nothing prevents you from having several sources and several diffs internally, see the dbs, cdbs and dpatch packages, for example (if you want real usage examples, look for source packages which have those in the Build-Depends). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
$BL$>5Bz9-9p"((B5000$B1_$G3+6H(B$B$7$^$;$s$+!*(B
(B $BL$>5Bz9-9p"((B $B$4LBOG$JJ}$O:o=|$7$F$/[EMAIL PROTECTED](B
$B!!Ev9-9p$rkM[;T;{ED#8!]#2(B
(B$BBeI=uBV$G$9!#:#Bg>fIW$G$b(B
$B$"$J$?$K$$$D%j%9%H%iEy$NIT9,$,=1$C$F$/$k$+$o$+$j$^$;$s!#(B
$B$^$?0lHL=nL1$,2?$+;v6H$r$d$m$&$H;W$C$F$b;q6bLL$J$I$GMF0W$K(B
$B=PMh$k$b$N$G$O$"$j$^$;$s!#(B
$B!!2a5n$r?6$jJV$C$F$_$F$"$N;~$"$l$r$7$F$*$1$PNI$+$C$?$H$+!"$"$N;~<+J,(B
$B$K$O$9$4$$%A%c%s%9$,$*K,[EMAIL PROTECTED];W$&$3$H$O$"$j$^$;$s$+!)(B
$B$=$N;~pJs$N;~Be$G$9!#3FpJs$,K~0n$G$9$,$?$C$?$N#5#0#0#01_$G-Mh$NIT0B$+$i2rJ|$5$l$=$N$&$(>!$AAH$N0l?M$K$J$l$kH&$G$9!#(B
$B!!$=$l$G$O7rF.$r4|BT$7$^$9!#4hD%$C$F$/[EMAIL
(BPROTECTED]:#$N>uBV$+$iC&=P$7$^$7$g$&!*!*(B
(B
(B $BI4J9$O0l8+$KG!$+$:(B,5000$B1_$G3+6H$7$F$_$^$;$s$+(B!!
(B
(B
(B http://dreamhand.cjb.net/
$B(B
(B
(B
(B $B(B
$B(B
(B
(B
(B--
(BTo UNSUBSCRIBE, email to [EMAIL PROTECTED]
(Bwith a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 11:06:35AM -0500, Jay Berkenbilt wrote: > Now I'm strongly considering making the switch to Debian and am > evaluating moving my whole installation system over to dpkg. dpkg > seems superior to rpm in almost all respects (richer dependencies, > better documentation, more robustness, apt, etc.), but there's one > thing that bothers me. When building an rpm, multiple source files > and multiple patch files can be specified, and arbitrary commands can > be used to extract sources and apply patches. This makes it easy to > build an rpm of a standard package with a handful of separately > maintained patches applied. While multiple patches are certainly advantageous (and are, I believe, intended to be supported in the next version of the Debian source package format), I don't like the idea of arbitrary commands to extract sources and apply patches. I very much prefer being able to unpack and examine the source of a package without trusting the person who created it. There are various systems used in Debian which pack multiple patches into the Debian .diff (see dpatch, cdbs, etc.). > As far as I can tell, a Debian package consists of a single source > tarball and a single diff. Is this right, or have I missed something? > Coming from an rpm perspective, it seems to me that this would make it > much more difficult to manage locally modified versions of packages. I prefer to use CVS (see the cvs-buildpackage package) to maintain local branches of Debian packages. Since CVS doesn't separate patches either, there isn't much lost there. > Lastly, please feel free to correct my terminology if I'm using it > incorrectly. For example, is it correct to say dpkg-based rather than > deb-based? dpkg is a program which operates on Debian packages. "deb" is a common shorthand for the Debian binary package format. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 05:56:33PM +0100, Thomas Viehmann <[EMAIL PROTECTED]> wrote: > It is also not uncommon to make an orig.tar.gz of (possibly multiple) > upstream tarballs by putting them in a directory and tarring that. Ofcourse you mean tar+gzip that, as orig is always tar.gz; alhough I think it's quite unefficient to have upstream source in tar.bz2 in some dir, and tar.gz it into orig.tar.gz ... Sometimes I feel that it would be better to utilize source mirrors. I mean Debian ftp servers would carry the diff.gz+dsc files, but not the package source (orig.tar.gz) - instead a mirror list for that source should be maintained, and automagically downloaded by 'apt-get source' from the first available. Cheers, GCS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian packages: single diff vs multiple patches (as in rpm)
On Tue, Dec 30, 2003 at 08:55:55PM +0100, GCS wrote: > On Tue, Dec 30, 2003 at 05:56:33PM +0100, Thomas Viehmann <[EMAIL PROTECTED]> wrote: > > It is also not uncommon to make an orig.tar.gz of (possibly multiple) > > upstream tarballs by putting them in a directory and tarring that. > Ofcourse you mean tar+gzip that, as orig is always tar.gz; alhough I > think it's quite unefficient to have upstream source in tar.bz2 in some > dir, and tar.gz it into orig.tar.gz ... Sometimes I feel that it would > be better to utilize source mirrors. I mean Debian ftp servers would > carry the diff.gz+dsc files, but not the package source (orig.tar.gz) - > instead a mirror list for that source should be maintained, and > automagically downloaded by 'apt-get source' from the first available. In addition to unnecessarily complicating what is currently a simple and reliable process, this would violate the licenses of much of the software that Debian distributes. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
