Re: Is this sufficient for an application?
On Sunday 08 February 2004 12:43, Florian Effenberger wrote: Hi Thomas, Well, I'd probably tell you to stick around some more and try to submit bugs with patches or do whatever you do. If you're not doing package maintentance you'd probably not be in a hurry to become a developer anyway. There's quite a few applicants or new maintainers that are probably much wider known for their work on various areas (e.g. Joe, Nathanial, Frank, ...). OTOH, obviously someone advocated you last time around. But I'm not a DD, so I have no say in it anyway. Well, I've been waiting for quite a while, and if I want to start more projects with Debian, now it's time to become an official developer. :-) So I hope someone on the list with appropriate permissions could help me *g* Not to sound negative but .. What will you give to Debian directly? We do not really have marketing people per se. From your intro it looks like you could assist with the documentation projects. Perhaps with the new installer docs? We always need more and better documentation. Debian likes new blood, really we do (-: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is this sufficient for an application?
On Sunday 08 February 2004 12:43, Florian Effenberger wrote: Hi Thomas, Well, I'd probably tell you to stick around some more and try to submit bugs with patches or do whatever you do. If you're not doing package maintentance you'd probably not be in a hurry to become a developer anyway. There's quite a few applicants or new maintainers that are probably much wider known for their work on various areas (e.g. Joe, Nathanial, Frank, ...). OTOH, obviously someone advocated you last time around. But I'm not a DD, so I have no say in it anyway. Well, I've been waiting for quite a while, and if I want to start more projects with Debian, now it's time to become an official developer. :-) So I hope someone on the list with appropriate permissions could help me *g* Not to sound negative but .. What will you give to Debian directly? We do not really have marketing people per se. From your intro it looks like you could assist with the documentation projects. Perhaps with the new installer docs? We always need more and better documentation. Debian likes new blood, really we do (-:
Re: Question about binary placement
On Sunday 10 August 2003 15:14, Stephen Gran wrote: Any comments on this? Am I making wrong assumptions here? My understanding is that one should avoid /usr/X11R6/bin when possible, and that's what I'm trying to accomplish. basically you are correct. Pretty much everything is dropped in /usr/bin these days. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about binary placement
On Sunday 10 August 2003 15:14, Stephen Gran wrote: Any comments on this? Am I making wrong assumptions here? My understanding is that one should avoid /usr/X11R6/bin when possible, and that's what I'm trying to accomplish. basically you are correct. Pretty much everything is dropped in /usr/bin these days.
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
On Thursday 24 July 2003 12:10, Colin Watson wrote: On Thu, Jul 24, 2003 at 08:26:14PM +0200, Marc Haber wrote: for one of my packages, later lintian versions emit a Warning saying: W: snoopy: sharedobject-in-library-directory-not-actually-a-shlib lib/snoopy.so That suggests that it's not a shared library *at all*, even discounting versions and so on. What do 'file' and 'objdump -p' say about that file? correct, so it does not belong in /usr/lib, it belongs in /usr/lib/snoopy or some such location. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
On Thursday 24 July 2003 12:10, Colin Watson wrote: On Thu, Jul 24, 2003 at 08:26:14PM +0200, Marc Haber wrote: for one of my packages, later lintian versions emit a Warning saying: W: snoopy: sharedobject-in-library-directory-not-actually-a-shlib lib/snoopy.so That suggests that it's not a shared library *at all*, even discounting versions and so on. What do 'file' and 'objdump -p' say about that file? correct, so it does not belong in /usr/lib, it belongs in /usr/lib/snoopy or some such location.
Re: What to do if $PACKAGE needs $ACCOUNT to _build_
On Sunday 08 June 2003 11:51, Marc Haber wrote: Hi, I am currently preparing packages for rrfw (see bug#186828). The daemons that come with rrfw run as user rrfw, and the Makefiles of that package insist on chowning some files to rrfw at build time. That - of course - fails when the rrfw account does not exist at build time. How am I supposed to handle this? Shall I change the build mechanisms so that the account is not needed at build time, shall I pester upstream to have that changed, or is there a workaround available? Any hints will be appreciated. Well, you could do the chown at install time inside the postinst. That should solve the problem nicely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do if $PACKAGE needs $ACCOUNT to _build_
On Sunday 08 June 2003 11:51, Marc Haber wrote: Hi, I am currently preparing packages for rrfw (see bug#186828). The daemons that come with rrfw run as user rrfw, and the Makefiles of that package insist on chowning some files to rrfw at build time. That - of course - fails when the rrfw account does not exist at build time. How am I supposed to handle this? Shall I change the build mechanisms so that the account is not needed at build time, shall I pester upstream to have that changed, or is there a workaround available? Any hints will be appreciated. Well, you could do the chown at install time inside the postinst. That should solve the problem nicely.
Re: [OT] OS Design Book Recommendations
Modern Operating Systems - 2nd Edition Andrew Tanenbaum. Well reviewed. Tanenbaum is a leading author in the field (as well as network theory). I wouldn't discount this book in a hurry. Does it have the OS reviews in it, though? this one is used as the OS book in many colleges. You can often find a used copy.
Re: Replacing a package with a newer, renamed version of itself.
On Friday 18 April 2003 20:04, Paul Hampson wrote: I'm currently playing with FreeRadius, which was in unstable as radiusd-freeradius but was removed due to a grave bug against it, which was only supposed to keep it out of testing. It never appeared in a stable Debian release, so the archive has forgotten all about it. Now, to deal with these two changes, I'm expecting to have to do the following: Put a note in README.Debian about the moved config files. Conflicts: and Replaces: radiusd-freeradius the conflicts and replaces make a new install of the package over the old one go smoothly. However, it will not cause apt to automatically move to the new package.
Re: Does a package name have to match path names?
On Wednesday 09 April 2003 17:51, Brett Cundal wrote: Hi mentors, First, I have an opinion question: I'm maintaining the gnu-smalltalk package, and I'm considering splitting it up into several packages (X and non-X for starters). If I do so, the resulting packages will have rather long names (gnu-smalltalk-common springs to mind). Would it be a good idea to rename the package gst? It's nice and short, and the interpreter executable is called gst. Is it considered bad form to rename a package unless absolutely neccesary? AFAIK, it's not technically difficult in a case like this. remember, some people go hunting for packages knowing only the upstream name. When at all possible it is a good idea to name it whatever they do while following Debian conventions. As for the name being too long, that is ok, don't worry about it. We have things like libperl-foo-bar-baz too. Secondly, supposing I did rename the package, is it okay to keep installing to /usr/share/gnu-smalltalk, /usr/lib/gnu-smalltalk, etc? Does the install path have to match the package name (i.e. /usr/share/gst)? The previous maintainer moved the default installation location (/usr/share/smalltalk) seemingly only to match the package name, and I'm curious if that was neccesary. I don't see anything indicating that in Policy or the FHS... If I change the install directory for whatever reason, could that break anything? again, it is a good idea to mimic the upstream. failing that, yes it is preferable for the path to match the package name.
Re: upstream bugs
On Saturday 29 March 2003 14:22, Andrew Stribblehill wrote: Quoting Tommaso Moroni [EMAIL PROTECTED] (2003-03-29 06:57:00 GMT): Should I wait for a new upstream release or should I apply the fixes to the current packages to get rid of those bugs as soon as possible? I consider it my duty to apply bug-fixes that I've patched to the Debian packages I maintain. For one thing, it gives the Debian package extra value; for another, it shows that a patch has received relatively wide testing. Regarding extra features I've implemented that Upstream is still pondering over, these I tend to incorporate but only if they affect very little code and the rest of the software can be used even if the feature turns out to be buggy. In these cases, I mark the feature as experimental in the Debian changelog. you should be careful however. Some upstreams dislike the dillution of the project. I have seen upstreams refuse to deal with anyone not using their source (and that is their right). There is also the issue of someone who used Debian in one place (school, home) and some other linux elsewhere (work, etc). Getting different behavior in each place can confuse and annoy the user. For bugs, each one is different. If the bug is sufficiently bad to get people to say bad things about Debian (things like I can't use apache at work, Debian's is sooo badly broken) then by all means make it right. Usually the bugs are minor and can wait a week or three. As for Andrew's feature additions I would say almost never. Unless the upstream is VERY slow, near abandoning, or has given approval. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upstream bugs
On Saturday 29 March 2003 14:22, Andrew Stribblehill wrote: Quoting Tommaso Moroni [EMAIL PROTECTED] (2003-03-29 06:57:00 GMT): Should I wait for a new upstream release or should I apply the fixes to the current packages to get rid of those bugs as soon as possible? I consider it my duty to apply bug-fixes that I've patched to the Debian packages I maintain. For one thing, it gives the Debian package extra value; for another, it shows that a patch has received relatively wide testing. Regarding extra features I've implemented that Upstream is still pondering over, these I tend to incorporate but only if they affect very little code and the rest of the software can be used even if the feature turns out to be buggy. In these cases, I mark the feature as experimental in the Debian changelog. you should be careful however. Some upstreams dislike the dillution of the project. I have seen upstreams refuse to deal with anyone not using their source (and that is their right). There is also the issue of someone who used Debian in one place (school, home) and some other linux elsewhere (work, etc). Getting different behavior in each place can confuse and annoy the user. For bugs, each one is different. If the bug is sufficiently bad to get people to say bad things about Debian (things like I can't use apache at work, Debian's is sooo badly broken) then by all means make it right. Usually the bugs are minor and can wait a week or three. As for Andrew's feature additions I would say almost never. Unless the upstream is VERY slow, near abandoning, or has given approval.
Re: [OT] A question for programmers - Inspiration
On Thursday 20 March 2003 21:30, Barry deFreese wrote: Thank you for the advice it is much appreciated. I should have gone a little futher in my background. I have done quite a bit of programming. I learned FORTRAN/77, Basic on VMS, and Cobol on VMS in college. I have written in VB, VBScript, JavaScript. In fact part of my job today is writing Active Server Pages. So I have some of the concepts down to a degree. I will definetely check into the books and such you have suggested. However, two of my fundamental problems are thus: I don't learn a great deal from reading unfortunately. I am pretty much a hands on guy with a background in networking and infrastructure stuff. Two ( too Chad's point ) the problem is, is that when I have an enlightenment, I guess I get intimidated because the things that I want to do are well above my skillsets. I want to write kernel level stuff when I'm lucky to write my name!! :-) (Somewhat of a chicken before the egg type of syndrome I suppose). I don't want to walk into flying, I want to fly into flying!! :-) in my experience as a programmer each time I truly learned something and reached that next plateau it was because something in work or hobby forced me to stretch that extra mile. Sometimes it is like having your bones broken so they can reset properly -- it always hurts and scares you. Then suddenly -- WHAMO -- the next time you are confronted with a big problem it does not seem as big. programming is like growing up. You crawl, then stumble, then walk and finally you run. Sometimes you learn to swim or mountain climb and these seem unrelated. Then the extra muscle / tone / fitness you gain helps you out in other ways. In physical engineering if you mess up you may destroy precious materials or otherwise impact the world. With a computer the only real cost is time. Remember, we learn more from our mistakes than our triumphs. Skin a knee, scrape your knuckles, break a bone. You'll be a better programmer for it. Finally I would like to comment on the book recommendations. These are spot on. If you look at the collections of people who have programmed for a while and take it seriously they tend to have books about thought processes, the act of programming and the like. These often outnumber the language specific texts 2 or 3 to 1. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] A question for programmers - Inspiration
On Thursday 20 March 2003 21:30, Barry deFreese wrote: Thank you for the advice it is much appreciated. I should have gone a little futher in my background. I have done quite a bit of programming. I learned FORTRAN/77, Basic on VMS, and Cobol on VMS in college. I have written in VB, VBScript, JavaScript. In fact part of my job today is writing Active Server Pages. So I have some of the concepts down to a degree. I will definetely check into the books and such you have suggested. However, two of my fundamental problems are thus: I don't learn a great deal from reading unfortunately. I am pretty much a hands on guy with a background in networking and infrastructure stuff. Two ( too Chad's point ) the problem is, is that when I have an enlightenment, I guess I get intimidated because the things that I want to do are well above my skillsets. I want to write kernel level stuff when I'm lucky to write my name!! :-) (Somewhat of a chicken before the egg type of syndrome I suppose). I don't want to walk into flying, I want to fly into flying!! :-) in my experience as a programmer each time I truly learned something and reached that next plateau it was because something in work or hobby forced me to stretch that extra mile. Sometimes it is like having your bones broken so they can reset properly -- it always hurts and scares you. Then suddenly -- WHAMO -- the next time you are confronted with a big problem it does not seem as big. programming is like growing up. You crawl, then stumble, then walk and finally you run. Sometimes you learn to swim or mountain climb and these seem unrelated. Then the extra muscle / tone / fitness you gain helps you out in other ways. In physical engineering if you mess up you may destroy precious materials or otherwise impact the world. With a computer the only real cost is time. Remember, we learn more from our mistakes than our triumphs. Skin a knee, scrape your knuckles, break a bone. You'll be a better programmer for it. Finally I would like to comment on the book recommendations. These are spot on. If you look at the collections of people who have programmed for a while and take it seriously they tend to have books about thought processes, the act of programming and the like. These often outnumber the language specific texts 2 or 3 to 1.
Re: Upload just to change maintainer to @d.o?
On Tuesday 04 March 2003 12:45, Michael Banck wrote: What is the recommended practice on uploading new versions of packages just for minor changes like this? Should I upload new versions of all of my packages, or wait to upload each package until there is a more significant user-visible change? I don't know if there is a policy on this. I'd recommend switching to your @d.o address as you're doing regular uploads. If by the time of the freeze there are still packages left with your old address, an upload just to fix that is alright. That's just MHO, YMMV. this is probably the best practice provided the information in the package header is still valid. If the old email address stops functioning a new upload is warranted. Also, if the package changes very infrequently it may make sense to upload a new package now than say 8 months from now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upload just to change maintainer to @d.o?
On Tuesday 04 March 2003 12:45, Michael Banck wrote: What is the recommended practice on uploading new versions of packages just for minor changes like this? Should I upload new versions of all of my packages, or wait to upload each package until there is a more significant user-visible change? I don't know if there is a policy on this. I'd recommend switching to your @d.o address as you're doing regular uploads. If by the time of the freeze there are still packages left with your old address, an upload just to fix that is alright. That's just MHO, YMMV. this is probably the best practice provided the information in the package header is still valid. If the old email address stops functioning a new upload is warranted. Also, if the package changes very infrequently it may make sense to upload a new package now than say 8 months from now.
Re: Kopete Now Listening Plugin
On Saturday 22 February 2003 08:00, Graham Wilson wrote: On Sat, Feb 22, 2003 at 09:28:32AM +0100, Till Gerken wrote: These are the options Sean Perry (my sponsor) and I have come up with: - remove xmms from the dependency list and move it to suggests (which is not handled by apt) i think this would be the best option. my concern here, as I told Till, was that he would be shipping a package which would fail for some people right out of the box. Debian has long had a tradition that once a package was installed it was fully functioning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to install images without getting executable-not-elf-or-script error?
On Wednesday 12 February 2003 21:12, David Grant wrote: Hi everyone, I have a simple package with one binary and a bunch of images should go into /usr/share/games/gav/themes/classic I basically modified the upstream Makefile, and changed the install target to look as follows: install: all install -d $(DESTDIR)/usr/bin $(DESTDIR)/usr/share/games/gav/themes/classic install ./gav $(DESTDIR)/usr/bin install ./themes/classic/* $(DESTDIR)/usr/share/games/gav/themes/classic I had actually changed the last line from something like cp -r ./themes/* /usr/share/games/gav/themes, because I figured using install was more proper. you can use install, cp, or whatever. The error you are seeing is probably because the files have the executable bit set in their permissions. The files should be rw or just r not rwx or r-x. Since you use install you need to pass the -m option and do something like -m 644 (owner has read nad write, everyone else has read). install by default sets the mode to 755 (rwxr-xr-x).
Re: Lintain changelog-file-not-compressed error: how can I fix this?
On Wednesday 12 February 2003 19:37, David Grant wrote: Hi, I'm getting this Lintain error for my package called gav: E: gav: changelog-file-not-compressed CHANGELOG CHANGELOG is the upstream changelog for the source package and it is in the package source root directory. I have it listed in my debian/docs file along with the upstream README file. It says I can compress it using 'gzip -9'. I tried this, and modified the debian/docs file...but then I get some error while creating the package: dpkg-source: cannot represent change to CHANGELOG.gz: binary file contents changed dpkg-source: warning: ignoring deletion of file CHANGELOG dpkg-source: building gav in gav_0.7.1-1.dsc dpkg-source: unrepresentable changes to source Thanks to anyone who can help me. You are supposed to gzip the Changelog during the install. Copy it to /usr/share/doc/package/CHANGELOG and then gzip it. You are not supposed to change the upstream tarball unless absolutely necessary. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintain changelog-file-not-compressed error: how can I fix this?
On Wednesday 12 February 2003 19:37, David Grant wrote: Hi, I'm getting this Lintain error for my package called gav: E: gav: changelog-file-not-compressed CHANGELOG CHANGELOG is the upstream changelog for the source package and it is in the package source root directory. I have it listed in my debian/docs file along with the upstream README file. It says I can compress it using 'gzip -9'. I tried this, and modified the debian/docs file...but then I get some error while creating the package: dpkg-source: cannot represent change to CHANGELOG.gz: binary file contents changed dpkg-source: warning: ignoring deletion of file CHANGELOG dpkg-source: building gav in gav_0.7.1-1.dsc dpkg-source: unrepresentable changes to source Thanks to anyone who can help me. You are supposed to gzip the Changelog during the install. Copy it to /usr/share/doc/package/CHANGELOG and then gzip it. You are not supposed to change the upstream tarball unless absolutely necessary.
Re: Install a file over the default
On Wednesday 29 January 2003 15:52, David Frey wrote: I am packaging a window manager and I want to replace one of the default config files with my own. My idea was to just call install from the postinst script, but I'm not sure exactly how I should do it. Am I taking the right approach here? I want to install ./app-version/debian/data/menu to /etc/X11/app/menu a window manager's menu should be autogenerated by using the tools provided in the menu package. This way adding/removing/changing packages automatically updates the user's menu. In general if you are replacing an upstream file with your own you should do it at package creation time, not install time.
Re: Question about lintian's shell-script-fails-syntax-check
On Tuesday 28 January 2003 13:51, Bastian Kleineidam wrote: Marco, On Tue, Jan 28, 2003 at 09:39:15PM +0100, Marco Kuhlmann wrote: The scripts seem to work fine in spite of their syntax errors, but I am not sure how to convince lintian about that. Read file:///usr/share/doc/lintian/lintian.html/ch2.html#s2.4 for lintian overrides. Cheers, Bastian or perhaps come up with some logic to detect this kind of odd shell script.
Re: Packaging pekwm
On Sunday 05 January 2003 18:59, David Frey wrote:
On Sun, 2003-01-05 at 18:38, Sean 'Shaleh' Perry wrote:
Take a look at my package for the blackbox window manager. Should answer
most of your questions. If you still have any issues please respond to
this thread and we can work them out. (Let's keep it here so the next
person packaging a wm can search the mentors archive).
That's how I got started. I have been looking at various window manager
packages. I still can't figure out how my menu-method is supposed to
get copied over.
If you look at blackbox I use debhelper for this. Specifically
dh_installmenu.
Here is a blurb from the man page:
blurb
It also automatically generates the postinst and postrm commands needed
to interface with the debian menu package. See dh_installdeb(1) for an
explanation of how this works.
If a file named debian/package.menu exists, then it is installed into
usr/lib/menu/package in the package build directory. This is a debian
menu file. See menufile(5L) for its format.
If a file named debian/package.menu-method exits, then it is installed
into etc/menu-methods/package in the package build directory. This is a
debian menu method file.
/blurb
The code is not too hard (see /usr/bin/dh_installmenu):
code
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
my $menu=pkgfile($package,menu);
my $menu_method=pkgfile($package,menu-method);
if ($menu ne '') {
if (! -d $tmp/usr/lib/menu) {
doit(install,-d,$tmp/usr/lib/menu);
}
doit(install,-p,-m644,$menu,$tmp/usr/lib/menu/$package);
# Add the scripts if a menu-method file doesn't exist.
# The scripts for menu-method handle everything these do, too.
if ($menu_method eq ! $dh{NOSCRIPTS}) {
autoscript($package,postinst,postinst-menu);
autoscript($package,postrm,postrm-menu)
}
}
if ($menu_method ne '') {
if (!-d $tmp/etc/menu-methods) {
doit(install,-d,$tmp/etc/menu-methods);
}
doit(install,-p,$menu_method,$tmp/etc/menu-methods/$package);
if (! $dh{NOSCRIPTS}) {
autoscript($package,postinst,postinst-menu-method,
s/#PACKAGE#/$package/);
autoscript($package,postrm,postrm-menu-method,
s/#PACKAGE#/$package/);
}
}
}
/code
And in /usr/share/debhelper/autoscripts:
$ cat postinst-menu-method
inst=/etc/menu-methods/#PACKAGE#
if [ -x /usr/bin/update-menus ] [ -f $inst ] ; then
chmod a+x $inst
update-menus
fi
Hope all of that helps and also gives you ideas on how to track down answers
to similar questions in the future. Even if you choose not to use debhelper,
Joey Hess does a great job of defining policy compliant and package
indepedent solutions to common issues. The code in debhelper is a worthwhile
read.
Re: Packaging pekwm
On Sunday 05 January 2003 11:53, David Frey wrote: I am trying to package pekwm for debian. I have a few questions about this. I have created a menu-method file which generates the menu correctly, but I don't know how to include it in the packages so that it gets installed and run. What do I have to do? Pekwm has multiple configuration files (autoprops config keys menu mouse start) and a directory called themes which holds other directories each corresponding to a different theme. Where should this stuff be installed to for debian? Should the themes be in /usr/share/pekwm/themes and the config files be in /etc/X11/pekwm/? Thanks Take a look at my package for the blackbox window manager. Should answer most of your questions. If you still have any issues please respond to this thread and we can work them out. (Let's keep it here so the next person packaging a wm can search the mentors archive). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging pekwm
On Sunday 05 January 2003 18:59, David Frey wrote:
On Sun, 2003-01-05 at 18:38, Sean 'Shaleh' Perry wrote:
Take a look at my package for the blackbox window manager. Should answer
most of your questions. If you still have any issues please respond to
this thread and we can work them out. (Let's keep it here so the next
person packaging a wm can search the mentors archive).
That's how I got started. I have been looking at various window manager
packages. I still can't figure out how my menu-method is supposed to
get copied over.
If you look at blackbox I use debhelper for this. Specifically
dh_installmenu.
Here is a blurb from the man page:
blurb
It also automatically generates the postinst and postrm commands needed
to interface with the debian menu package. See dh_installdeb(1) for an
explanation of how this works.
If a file named debian/package.menu exists, then it is installed into
usr/lib/menu/package in the package build directory. This is a debian
menu file. See menufile(5L) for its format.
If a file named debian/package.menu-method exits, then it is installed
into etc/menu-methods/package in the package build directory. This is a
debian menu method file.
/blurb
The code is not too hard (see /usr/bin/dh_installmenu):
code
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
my $menu=pkgfile($package,menu);
my $menu_method=pkgfile($package,menu-method);
if ($menu ne '') {
if (! -d $tmp/usr/lib/menu) {
doit(install,-d,$tmp/usr/lib/menu);
}
doit(install,-p,-m644,$menu,$tmp/usr/lib/menu/$package);
# Add the scripts if a menu-method file doesn't exist.
# The scripts for menu-method handle everything these do, too.
if ($menu_method eq ! $dh{NOSCRIPTS}) {
autoscript($package,postinst,postinst-menu);
autoscript($package,postrm,postrm-menu)
}
}
if ($menu_method ne '') {
if (!-d $tmp/etc/menu-methods) {
doit(install,-d,$tmp/etc/menu-methods);
}
doit(install,-p,$menu_method,$tmp/etc/menu-methods/$package);
if (! $dh{NOSCRIPTS}) {
autoscript($package,postinst,postinst-menu-method,
s/#PACKAGE#/$package/);
autoscript($package,postrm,postrm-menu-method,
s/#PACKAGE#/$package/);
}
}
}
/code
And in /usr/share/debhelper/autoscripts:
$ cat postinst-menu-method
inst=/etc/menu-methods/#PACKAGE#
if [ -x /usr/bin/update-menus ] [ -f $inst ] ; then
chmod a+x $inst
update-menus
fi
Hope all of that helps and also gives you ideas on how to track down answers
to similar questions in the future. Even if you choose not to use debhelper,
Joey Hess does a great job of defining policy compliant and package
indepedent solutions to common issues. The code in debhelper is a worthwhile
read.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging pekwm
On Sunday 05 January 2003 11:53, David Frey wrote: I am trying to package pekwm for debian. I have a few questions about this. I have created a menu-method file which generates the menu correctly, but I don't know how to include it in the packages so that it gets installed and run. What do I have to do? Pekwm has multiple configuration files (autoprops config keys menu mouse start) and a directory called themes which holds other directories each corresponding to a different theme. Where should this stuff be installed to for debian? Should the themes be in /usr/share/pekwm/themes and the config files be in /etc/X11/pekwm/? Thanks Take a look at my package for the blackbox window manager. Should answer most of your questions. If you still have any issues please respond to this thread and we can work them out. (Let's keep it here so the next person packaging a wm can search the mentors archive).
Re: blender
On Saturday 16 November 2002 09:13, Warren Turkal wrote: Is anyone maintaining blender? I mailed the maintainer and never got a response. Warren not really. If you want it, package it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: blender
On Saturday 16 November 2002 09:13, Warren Turkal wrote: Is anyone maintaining blender? I mailed the maintainer and never got a response. Warren not really. If you want it, package it.
Re: linuxworld expo 2003
On Tuesday 12 November 2002 00:10, Ross Boylan wrote: I'm in San Francisco, and this is the first I've heard about a Bay Area list. Could you tell me about it? Thanks. [EMAIL PROTECTED] go to http://bad.debian.net for details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linuxworld expo 2003
On Tuesday 12 November 2002 00:10, Ross Boylan wrote: I'm in San Francisco, and this is the first I've heard about a Bay Area list. Could you tell me about it? Thanks. [EMAIL PROTECTED] go to http://bad.debian.net for details.
Re: linuxworld expo 2003
On Sunday 10 November 2002 13:08, Samuel Desseaux wrote: Hi! excuse me, before all, if i am a bit out of the subject of the list. Who plan to take part at the next linuxworld expo in 2003 (in New-york or San francisco)? I've never take part in it but next year, i'd like it very much (like the free software meeting in france, it seems to be a good opportunitie to learn and meet some developers). So, if someone has the experience of this event, write me!! thanks sam If it is held again in San Francisco (economy, tech market, etc) I usually take charge of the booth here. As the time comes closer we discuss somethings here and on a Bay Area mailing list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linuxworld expo 2003
On Sunday 10 November 2002 13:08, Samuel Desseaux wrote: Hi! excuse me, before all, if i am a bit out of the subject of the list. Who plan to take part at the next linuxworld expo in 2003 (in New-york or San francisco)? I've never take part in it but next year, i'd like it very much (like the free software meeting in france, it seems to be a good opportunitie to learn and meet some developers). So, if someone has the experience of this event, write me!! thanks sam If it is held again in San Francisco (economy, tech market, etc) I usually take charge of the booth here. As the time comes closer we discuss somethings here and on a Bay Area mailing list.
Re: upstream author only distributes in zip format
On Saturday 09 November 2002 19:08, Marc Nozell wrote: I'm starting to package up a tool and have some questions about 'pristine source'. * The upstream author only distributes as a ZIP file. Since dpkg-buildpackage, dh_make, etc only understand .tar.gz files, is it acceptable for me to grab the .zip, unpackage it, create a tar.gz and then start the packaging process? I'm not touching the contents of the archive, just the archive format. * The upstream author also names his releases as packagename-0+5i, the previous being packagename-0+4i. Along the same lines as above, is it acceptable to rename the file to packagename-0.5i? Thanks! -marc sometimes we have to add a little sanity to an otherwise crazy world. (-: The guidelines cover the most common issues, but there are always exceptions.
Re: upstream author only distributes in zip format
On Saturday 09 November 2002 19:08, Marc Nozell wrote: I'm starting to package up a tool and have some questions about 'pristine source'. * The upstream author only distributes as a ZIP file. Since dpkg-buildpackage, dh_make, etc only understand .tar.gz files, is it acceptable for me to grab the .zip, unpackage it, create a tar.gz and then start the packaging process? I'm not touching the contents of the archive, just the archive format. * The upstream author also names his releases as packagename-0+5i, the previous being packagename-0+4i. Along the same lines as above, is it acceptable to rename the file to packagename-0.5i? Thanks! -marc sometimes we have to add a little sanity to an otherwise crazy world. (-: The guidelines cover the most common issues, but there are always exceptions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which compiler
On Tuesday 05 November 2002 08:03, Bas Zoetekouw wrote: Hi Bob! You wrote: For the 1386 architecture, sid has gcc 2:2.95.4-17 and gcc-3.0 1:3.0.4-13. Which compiler should be used for an Architecture: any package? The default one for the architecture in question. If the answer is gcc-3.0, should that be included in the build-depends? No, and neither should any other build-essential packages be included in the build-depends. However if you MUST use gcc 3.0 for some reason you do need to build-depend on it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which compiler
On Tuesday 05 November 2002 08:03, Bas Zoetekouw wrote: Hi Bob! You wrote: For the 1386 architecture, sid has gcc 2:2.95.4-17 and gcc-3.0 1:3.0.4-13. Which compiler should be used for an Architecture: any package? The default one for the architecture in question. If the answer is gcc-3.0, should that be included in the build-depends? No, and neither should any other build-essential packages be included in the build-depends. However if you MUST use gcc 3.0 for some reason you do need to build-depend on it.
Re: Request for sponsor: PornView
On Monday 04 November 2002 01:24, Jamie Wilkinson wrote: This one time, at band camp, Brian Nelson wrote: * Package name: pornview Version : 0.1.0 Upstream Author : trem0r [EMAIL PROTECTED] * URL : http://pornview.sourceforge.net/ * License : GPL Description : GTK+-based image viewer/manager PornView is a GTK+-based image viewer/manager. Features include thumbnail previews, thumbnail caching, directory tree views, and adjustable zoom. Fullscreen view and slideshows allow for basic presentation of images. What advantages does pornview have over, say, gqview, which allows one-handed operation in addition to all these features? can't see anything other than a slightly different layout and the word 'porn' in its name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for sponsor: PornView
On Monday 04 November 2002 01:24, Jamie Wilkinson wrote: This one time, at band camp, Brian Nelson wrote: * Package name: pornview Version : 0.1.0 Upstream Author : trem0r [EMAIL PROTECTED] * URL : http://pornview.sourceforge.net/ * License : GPL Description : GTK+-based image viewer/manager PornView is a GTK+-based image viewer/manager. Features include thumbnail previews, thumbnail caching, directory tree views, and adjustable zoom. Fullscreen view and slideshows allow for basic presentation of images. What advantages does pornview have over, say, gqview, which allows one-handed operation in addition to all these features? can't see anything other than a slightly different layout and the word 'porn' in its name.
Re: Looking for a sponsor
On Thursday 31 October 2002 08:14, Ken Bloom wrote: If you're interested, email me and I can send you the packages. I'm not sure which files I would need to make available on a web site for you to look at, so please tell me which of the package files you need. --Ken Bloom In general you upload everything -- the orig.tar.gz, the diff.gz and the dsc as well as the final deb package. This lets whoever is interested look at how you did the packaging, run lintian/linda, etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a sponsor
On Thursday 31 October 2002 08:14, Ken Bloom wrote: If you're interested, email me and I can send you the packages. I'm not sure which files I would need to make available on a web site for you to look at, so please tell me which of the package files you need. --Ken Bloom In general you upload everything -- the orig.tar.gz, the diff.gz and the dsc as well as the final deb package. This lets whoever is interested look at how you did the packaging, run lintian/linda, etc.
Re: ELITE the New Kind packager is looking for a sponsor
On Wednesday 16 October 2002 10:08, Daniel A. Nagy wrote: Hi, I have compiled a debian package for the 32-bit revival of the classic 3D space-trading game ELITE (originally by Ian Bell and David Braben) done by Christian Pinder. I think that the package is worth becoming a part of Debian. Since the copyright status is unclrear (Chris Pinder didn't manage to obtain an explicit permission from D. Braben, but he received no objections either), the package should probably go into non-free/games section. I need a spondor for this package. Thank you! until the copyright is clear this can not be packaged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ELITE the New Kind packager is looking for a sponsor
On Wednesday 16 October 2002 10:08, Daniel A. Nagy wrote: Hi, I have compiled a debian package for the 32-bit revival of the classic 3D space-trading game ELITE (originally by Ian Bell and David Braben) done by Christian Pinder. I think that the package is worth becoming a part of Debian. Since the copyright status is unclrear (Chris Pinder didn't manage to obtain an explicit permission from D. Braben, but he received no objections either), the package should probably go into non-free/games section. I need a spondor for this package. Thank you! until the copyright is clear this can not be packaged.
Re: Replacing cron
On Sunday 06 October 2002 12:19, Sjoerd wrote:
Hello,
I recently tried to make a package of dcron to replace cron:
Package: dcron
Architecture: any
Depends: ${shlibs:Depends}
Recommends: exim | smail | sendmail | mail-transport-agent
Conflicts: cron
Provides: cron
Replaces: cron
...
However, this doesn't really work with logrotate for example, which depends
on cron (= 3.0pl1-53). I tried:
...
Provides: cron 4.0.0
...
Because I thought it was the version number why it didn't work. How do I
solve this? Is there a need for a virtual package cron?
Sjoerd
Provides can not provide a version (currently, may change some day). You can
ask for people to depend on cron | dcron. Although the question is now, why
a new cron??
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Replacing cron
On Sunday 06 October 2002 12:19, Sjoerd wrote:
Hello,
I recently tried to make a package of dcron to replace cron:
Package: dcron
Architecture: any
Depends: ${shlibs:Depends}
Recommends: exim | smail | sendmail | mail-transport-agent
Conflicts: cron
Provides: cron
Replaces: cron
...
However, this doesn't really work with logrotate for example, which depends
on cron (= 3.0pl1-53). I tried:
...
Provides: cron 4.0.0
...
Because I thought it was the version number why it didn't work. How do I
solve this? Is there a need for a virtual package cron?
Sjoerd
Provides can not provide a version (currently, may change some day). You can
ask for people to depend on cron | dcron. Although the question is now, why
a new cron??
Re: Control File
On Thursday 03 October 2002 08:56, Zeno Davatz wrote: My Debian tells me that I need to install apache-common. Why do the dependency-manager not know that I already got apache-ssl installed. I wrote in my control file that apache-ssl-ywesee replaces apache, apache-common, apache-ssl replaces means it is ok to install me over this other package. You need to Provide: apache-common. Or just take the Debian apache package, add you tweaks and use it locally. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Control File
On Thursday 03 October 2002 11:08, Sven LUTHER wrote: Mmm, is Provides a superset of Replaces, or do you have to specify both ? Replaces says it is ok to install me when this other package is installed, even if we have the same files, I now own those files. Provides says for all intents and purposes treat me as this other package when doing depends checks. So if package foo has file /etc/bar which used to be in package bar you say Replaces: bar. If package foo or package bar can be installed to satisfy the same depends you put a Provides: bar in foo's control file (or you have both of them Provide a psuedo package). If the package foo is not a 100% replacement for the bar package AND you intend to take over bar's place in the Debian archive you say both replaces and provides. If you want to remove the bar package from a user's machine while doing this you also specify a conflicts on bar. All of this is documented in policy is different (and perhaps better) words. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Control File
On Thursday 03 October 2002 11:05, Zeno Davatz wrote: If I do apt-get install php4 My Debian still asks me to install apache-common - Why? Thanks for your help. Zeno Because php4 depends on a version of apache-common and Provides does not help with version depends. As I commented earlier, you are probably best off grabbing the apache package, adding your options and using it rather than making your own package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Control File
On Thursday 03 October 2002 08:56, Zeno Davatz wrote: My Debian tells me that I need to install apache-common. Why do the dependency-manager not know that I already got apache-ssl installed. I wrote in my control file that apache-ssl-ywesee replaces apache, apache-common, apache-ssl replaces means it is ok to install me over this other package. You need to Provide: apache-common. Or just take the Debian apache package, add you tweaks and use it locally.
Re: Control File
On Thursday 03 October 2002 11:08, Sven LUTHER wrote: Mmm, is Provides a superset of Replaces, or do you have to specify both ? Replaces says it is ok to install me when this other package is installed, even if we have the same files, I now own those files. Provides says for all intents and purposes treat me as this other package when doing depends checks. So if package foo has file /etc/bar which used to be in package bar you say Replaces: bar. If package foo or package bar can be installed to satisfy the same depends you put a Provides: bar in foo's control file (or you have both of them Provide a psuedo package). If the package foo is not a 100% replacement for the bar package AND you intend to take over bar's place in the Debian archive you say both replaces and provides. If you want to remove the bar package from a user's machine while doing this you also specify a conflicts on bar. All of this is documented in policy is different (and perhaps better) words.
Re: Control File
On Thursday 03 October 2002 11:05, Zeno Davatz wrote: If I do apt-get install php4 My Debian still asks me to install apache-common - Why? Thanks for your help. Zeno Because php4 depends on a version of apache-common and Provides does not help with version depends. As I commented earlier, you are probably best off grabbing the apache package, adding your options and using it rather than making your own package.
Re: menu icon format
On Wednesday 02 October 2002 14:57, Mike Furr wrote: One of my packages just changed its icon from an xpm to png. I was all for it until I saw lintian complain: W: terminatorx: menu-icon-not-in-xpm-format /usr/share/pixmaps/terminatorX-app.png Do we ship wm's that can't handle pngs, but do handle our menu system? The menu sub-policy doesn't mention anything about formats... I'd rather not put a build-depend on imagemagick just for this... -m menu policy section 3.4. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: menu icon format
On Wednesday 02 October 2002 14:57, Mike Furr wrote: One of my packages just changed its icon from an xpm to png. I was all for it until I saw lintian complain: W: terminatorx: menu-icon-not-in-xpm-format /usr/share/pixmaps/terminatorX-app.png Do we ship wm's that can't handle pngs, but do handle our menu system? The menu sub-policy doesn't mention anything about formats... I'd rather not put a build-depend on imagemagick just for this... -m menu policy section 3.4.
Re: Questian about Architecture
On Wednesday 11 September 2002 13:35, Marco Kuhlmann wrote: Dear mentors, I do not quite seem to understand what I have to do in order to prevent a source package being ported to certain architectures. Do I have to write Architecture entries for the supported architectures for all the packages that my source package provides? It does not seem to be possible to write one Architecture entry for the whole source package. - Marco If a package is not Architecture: Any then you must list the architectures that are supported. Unfortunately there is no way to say for example: Arch: !hurd-i386 as much as some maintainers wish they could. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questian about Architecture
On Wednesday 11 September 2002 13:35, Marco Kuhlmann wrote: Dear mentors, I do not quite seem to understand what I have to do in order to prevent a source package being ported to certain architectures. Do I have to write Architecture entries for the supported architectures for all the packages that my source package provides? It does not seem to be possible to write one Architecture entry for the whole source package. - Marco If a package is not Architecture: Any then you must list the architectures that are supported. Unfortunately there is no way to say for example: Arch: !hurd-i386 as much as some maintainers wish they could.
RE: How much redundancy?
On 20-Aug-2002 Devin Carraway wrote: Fairly often I've seen ITPs or package sponsorship requests followed up to by questions about redundancy against packages already in Debian. Thus, I'm curious -- what degree of redundancy is acceptable or desirable? As big as a Debian distribution is, there's unavoidable overlap. It's easy to understand, say, choosing one particular ping implementation from a couple of functionally near-identical possibilities. However, one package could functionally be entirely provided by another, while still desirable by way of being smaller, simpler, written in Python or whatever. It seems reasonable to provide redundant packages when users could have a credible desire to use one or another (e.g. one of the half-dozen minimalist windowmanagers.) Is there a reigning convention? there is always a war between the old guard I remember when I could name every package in Debian off the top of my head versus the new generation of gFoo, kFoo, xFoo, myFoo, hisFoo. In the end I believe that as long as a package in Debian is being used by more than 1 person it has value. Let's fight the urge to just package something because it is interesting. However if there is a user base out there then Debian should support them. Our users should not have to compile software on their own. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: name collisions
On 20-Aug-2002 Henrique de Moraes Holschuh wrote: On Mon, 19 Aug 2002, Sean 'Shaleh' Perry wrote: Debian should try *very* hard to match the upstream names. otherwise any docs or 3rd party tools will not be happy under Debian. Also if a user sends them a Even when upstream uses such dumb names as reconstruct, master and so on? (dumb as in guaranteed to cause filesystem clashes) many of those can be solved by placing them in a special directory. And yes, sometimes we do have to step in (-:
RE: How much redundancy?
On 20-Aug-2002 Devin Carraway wrote: Fairly often I've seen ITPs or package sponsorship requests followed up to by questions about redundancy against packages already in Debian. Thus, I'm curious -- what degree of redundancy is acceptable or desirable? As big as a Debian distribution is, there's unavoidable overlap. It's easy to understand, say, choosing one particular ping implementation from a couple of functionally near-identical possibilities. However, one package could functionally be entirely provided by another, while still desirable by way of being smaller, simpler, written in Python or whatever. It seems reasonable to provide redundant packages when users could have a credible desire to use one or another (e.g. one of the half-dozen minimalist windowmanagers.) Is there a reigning convention? there is always a war between the old guard I remember when I could name every package in Debian off the top of my head versus the new generation of gFoo, kFoo, xFoo, myFoo, hisFoo. In the end I believe that as long as a package in Debian is being used by more than 1 person it has value. Let's fight the urge to just package something because it is interesting. However if there is a user base out there then Debian should support them. Our users should not have to compile software on their own.
RE: name collisions
Futhermore, I am a bit hesitant, since, to my opinion, nvrec is more active as compared to the original nuppel video tools, ... Also, is renaming of binaries for debian at the discresion of the debian maintainer (me) or should it be upstream (possibly interactive)? I guess we'll have to figure this one out ourselves, but if anyone would care to give his opinion, ... Debian should try *very* hard to match the upstream names. otherwise any docs or 3rd party tools will not be happy under Debian. Also if a user sends them a bug the upstream is likely to say huh? what is that?. It also makes it harder for the user to seek help from upstream mailing lists. In general I find that if I just package up the work of the original authors everything goes smoothly. Sometimes however you need to seek change. If it were my package I would not have asked the nv people to lowercase their binaries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: name collisions
On 20-Aug-2002 Henrique de Moraes Holschuh wrote: On Mon, 19 Aug 2002, Sean 'Shaleh' Perry wrote: Debian should try *very* hard to match the upstream names. otherwise any docs or 3rd party tools will not be happy under Debian. Also if a user sends them a Even when upstream uses such dumb names as reconstruct, master and so on? (dumb as in guaranteed to cause filesystem clashes) many of those can be solved by placing them in a special directory. And yes, sometimes we do have to step in (-: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: name collisions
Futhermore, I am a bit hesitant, since, to my opinion, nvrec is more active as compared to the original nuppel video tools, ... Also, is renaming of binaries for debian at the discresion of the debian maintainer (me) or should it be upstream (possibly interactive)? I guess we'll have to figure this one out ourselves, but if anyone would care to give his opinion, ... Debian should try *very* hard to match the upstream names. otherwise any docs or 3rd party tools will not be happy under Debian. Also if a user sends them a bug the upstream is likely to say huh? what is that?. It also makes it harder for the user to seek help from upstream mailing lists. In general I find that if I just package up the work of the original authors everything goes smoothly. Sometimes however you need to seek change. If it were my package I would not have asked the nv people to lowercase their binaries.
Re: Main, contrib or non-free?
Refer to the Debian Policy Manual, section 2.1.2. quote In addition, the packages in main * must not require a package outside of main for *compilation* or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) /quote (emphasis added) If the program cannot be compiled using free tools, then it is not very free. The idea of free software is to allow anyone to use, modify and redistribute the software for any purpose, and requiring proprietary software for modification restricts that freedom. it is perfectly reasonable to have a GPL app that can only be built by say MS VisualC++. Debian has chosen to further define what may go in main as programs which can be compiled on Debian with software shipped by Debian. This to is reasonable. If it can not be autobuilt by our build daemons it is not useful software. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Main, contrib or non-free?
Refer to the Debian Policy Manual, section 2.1.2. quote In addition, the packages in main * must not require a package outside of main for *compilation* or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) /quote (emphasis added) If the program cannot be compiled using free tools, then it is not very free. The idea of free software is to allow anyone to use, modify and redistribute the software for any purpose, and requiring proprietary software for modification restricts that freedom. it is perfectly reasonable to have a GPL app that can only be built by say MS VisualC++. Debian has chosen to further define what may go in main as programs which can be compiled on Debian with software shipped by Debian. This to is reasonable. If it can not be autobuilt by our build daemons it is not useful software.
Re: Why debhelper doesn't add /usr/doc/package links creation/re
Well, it seems we have to wait for new version of lintian in unstable. there is a bug on lintian, the solution is known. I am finishing up a project right now and then intend to devote several weeks to getting lintian up to speed. lintian is a sanity checker but you are free to questions ITS sanity. No where in Debian is lintian used to enforce any rules. It is solely a tool to help you the developer make better packages and reduce the time you spend doing so. This does not mean that you should ignore lintian all of the time. But sometimes it gets policy wrong or policy changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why debhelper doesn't add /usr/doc/package links creation/re
Well, it seems we have to wait for new version of lintian in unstable. there is a bug on lintian, the solution is known. I am finishing up a project right now and then intend to devote several weeks to getting lintian up to speed. lintian is a sanity checker but you are free to questions ITS sanity. No where in Debian is lintian used to enforce any rules. It is solely a tool to help you the developer make better packages and reduce the time you spend doing so. This does not mean that you should ignore lintian all of the time. But sometimes it gets policy wrong or policy changes.
RE: Orphan Packages
On 22-Jul-2002 Tom Miller wrote: Hello, I am not a Debian Developer, however I hope to be becoming one eventually, as has happened on this board, most people who would like to become a developer post a package to have someone sponser it. If I were to do this, however one of the packages I wanted sponsered was Orphaned, would the process be any different. I mean this on multiple levels, for example the files in debian/ like control, copyright, and changelog, how would the credit be placed, would I add my name to the list, or take the previous persons name off? Additionally, should i submit a response to the Orphan message in the WNPP list even though I'm not a developer? Would it get sponsered the same way? debian/control must list the current maintainer so it would have your name. The changelog would continue on with a new maintainer's name listed. Typically your first release documents the switch. copyright should contain the name(s) of the people who have done the packaging work. So if you add to the packaging you should add your name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Orphan Packages
On 22-Jul-2002 Tom Miller wrote: Hello, I am not a Debian Developer, however I hope to be becoming one eventually, as has happened on this board, most people who would like to become a developer post a package to have someone sponser it. If I were to do this, however one of the packages I wanted sponsered was Orphaned, would the process be any different. I mean this on multiple levels, for example the files in debian/ like control, copyright, and changelog, how would the credit be placed, would I add my name to the list, or take the previous persons name off? Additionally, should i submit a response to the Orphan message in the WNPP list even though I'm not a developer? Would it get sponsered the same way? debian/control must list the current maintainer so it would have your name. The changelog would continue on with a new maintainer's name listed. Typically your first release documents the switch. copyright should contain the name(s) of the people who have done the packaging work. So if you add to the packaging you should add your name. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Tight versions depends
On 14-Jul-2002 Jeff Bailey wrote:
I'm having some trouble I can't seem to find the answer to. Mailutils
creates both 'mailutils-pop3d', and 'libmailutils0'. The two need to
tightly depend on one another, since the ABI hasn't stabilized yet.
In my control file I have:
Depends: ${shlibs:Depends}, netbase, libmailutils0 (= ${Source-Version})
However, Lintian throws up on me for:
E: mailutils-imap4d: package-has-a-duplicate-relation libmailutils0,
libmailutils0 (= 20020713-1)
This is referred to as a bug in lintian. See the bts for more info (-:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tight versions depends
On 14-Jul-2002 Colin Watson wrote:
On Sun, Jul 14, 2002 at 10:14:30AM -0700, Sean 'Shaleh' Perry wrote:
On 14-Jul-2002 Jeff Bailey wrote:
Depends: ${shlibs:Depends}, netbase, libmailutils0 (= ${Source-Version})
However, Lintian throws up on me for:
E: mailutils-imap4d: package-has-a-duplicate-relation libmailutils0,
libmailutils0 (= 20020713-1)
This is referred to as a bug in lintian. See the bts for more info (-:
Is it? It does look like a duplicate relation to me (the second implies
the first) ...
Colin, you are right. I was thinking of situations like:
foo | bar, foo ( 2.2) | baz
Yeah, the shlibs needs to be adjusted or some other magic applied.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Tight versions depends
On 14-Jul-2002 Jeff Bailey wrote:
I'm having some trouble I can't seem to find the answer to. Mailutils
creates both 'mailutils-pop3d', and 'libmailutils0'. The two need to
tightly depend on one another, since the ABI hasn't stabilized yet.
In my control file I have:
Depends: ${shlibs:Depends}, netbase, libmailutils0 (= ${Source-Version})
However, Lintian throws up on me for:
E: mailutils-imap4d: package-has-a-duplicate-relation libmailutils0,
libmailutils0 (= 20020713-1)
This is referred to as a bug in lintian. See the bts for more info (-:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tight versions depends
On 14-Jul-2002 Colin Watson wrote:
On Sun, Jul 14, 2002 at 10:14:30AM -0700, Sean 'Shaleh' Perry wrote:
On 14-Jul-2002 Jeff Bailey wrote:
Depends: ${shlibs:Depends}, netbase, libmailutils0 (= ${Source-Version})
However, Lintian throws up on me for:
E: mailutils-imap4d: package-has-a-duplicate-relation libmailutils0,
libmailutils0 (= 20020713-1)
This is referred to as a bug in lintian. See the bts for more info (-:
Is it? It does look like a duplicate relation to me (the second implies
the first) ...
Colin, you are right. I was thinking of situations like:
foo | bar, foo ( 2.2) | baz
Yeah, the shlibs needs to be adjusted or some other magic applied.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Appeal to follow up on sponsor/advocate requests
On 25-Jun-2002 Ben Armstrong wrote: Hi, Looking over the past month or so of debian-mentors, I'm seeing that quite a number of people's appeals for sponsorship or advocacy are apparently falling on deaf ears (unless these are being answered only in private email). If regulars here would periodically scan the past week or more of debian-mentors archives to see if any have fallen through the cracks, we could keep on top of these. I have tried to get the ball rolling by answering a couple of sponsorship requests today, but there are several others with subjects containing sponsor, RFS, or in one case spronsor. I have answered one via private mail, the kopete maintainer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Depends: ${shlibs:Depends}
I am about that it makes the built binary package depending on environment in which is is built. But I think this is acceptable for alpha versions of software, which are more for developers than for normal users, yes? It is required for all packages that link against shared libraries, whether alpha or not. Regardless of what you put in the Depends: line, the built binary package does depend on the environment in which it is built, because of the way dynamic linking works. further, the environment you build a package in should be similar to the environment your users have. If this is not the case use one of the packages which creates a chroot for compiling packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: obsolete, harmful conf files
On 24-Jun-2002 Oliver Kurth wrote:
Hello!
I have changed a package and made some files in /etc/pcmcia/ip-{up,down}.d/
obsolete. Since they are in /etc they are conffiles. Since they are
conffiles, they will not be removed on upgrade. Since they are
also scripts, they are somewhat harmful.
Should I...
1) remove them quitely (probably not)
2) ask via debconf if they should be deleted
3) move them out of the way, if so, where?
4) do nothing (bad idea, here for completeness)
5) [insert a better answer here]
I did not find an answer in the policy, I hope I searched hard enough...
so by obsolete do they have new names? has the functionality moved elsewhere?
The real answer depends on if the user is going to lose functionality (or gain
unwanted functionality). If this is simply I have renamed these and put them
in /etc/foo you should be able to get away with debconf. But if there is a
possibilty the user (and this should be a fair number of users, not like 1 or
2) have seriously mod'ed the file you have a bigger problem on your hands and
should consider supporting both the old and the new files.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: obsolete, harmful conf files
The real answer depends on if the user is going to lose functionality (or
gain
unwanted functionality). If this is simply I have renamed these and put
them
in /etc/foo you should be able to get away with debconf. But if there is a
possibilty the user (and this should be a fair number of users, not like 1
or
2) have seriously mod'ed the file you have a bigger problem on your hands
and
should consider supporting both the old and the new files.
In principle they have moved to another location,
/etc/network/if-{up,down}.d,
and at the same I have greatly changed them. What happens if they are not
removed is that both of them will be executed. They both start a process
in background (fetch and/or send mail). Whatever will be executed first
will block (by a lock file) the second, because it is likely that the
time span between them is short. The old scripts also depend on a conf file
which is obsolete as well (it is still there, because it is a conffile, but
not supported by debconf).
My worries are that I get lots of bug reports because the package does not
behave as expected by the users.
So why not chmod -x them in your postinst and pop up a debconf note that
explains the new situation. The scripts are not removed, they are simply
disabled. Also document this in your changelog and in README.Debian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Depends: ${shlibs:Depends}
I am about that it makes the built binary package depending on environment in which is is built. But I think this is acceptable for alpha versions of software, which are more for developers than for normal users, yes? It is required for all packages that link against shared libraries, whether alpha or not. Regardless of what you put in the Depends: line, the built binary package does depend on the environment in which it is built, because of the way dynamic linking works. further, the environment you build a package in should be similar to the environment your users have. If this is not the case use one of the packages which creates a chroot for compiling packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: obsolete, harmful conf files
On 24-Jun-2002 Oliver Kurth wrote:
Hello!
I have changed a package and made some files in /etc/pcmcia/ip-{up,down}.d/
obsolete. Since they are in /etc they are conffiles. Since they are
conffiles, they will not be removed on upgrade. Since they are
also scripts, they are somewhat harmful.
Should I...
1) remove them quitely (probably not)
2) ask via debconf if they should be deleted
3) move them out of the way, if so, where?
4) do nothing (bad idea, here for completeness)
5) [insert a better answer here]
I did not find an answer in the policy, I hope I searched hard enough...
so by obsolete do they have new names? has the functionality moved elsewhere?
The real answer depends on if the user is going to lose functionality (or gain
unwanted functionality). If this is simply I have renamed these and put them
in /etc/foo you should be able to get away with debconf. But if there is a
possibilty the user (and this should be a fair number of users, not like 1 or
2) have seriously mod'ed the file you have a bigger problem on your hands and
should consider supporting both the old and the new files.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: obsolete, harmful conf files
The real answer depends on if the user is going to lose functionality (or
gain
unwanted functionality). If this is simply I have renamed these and put
them
in /etc/foo you should be able to get away with debconf. But if there is a
possibilty the user (and this should be a fair number of users, not like 1
or
2) have seriously mod'ed the file you have a bigger problem on your hands
and
should consider supporting both the old and the new files.
In principle they have moved to another location,
/etc/network/if-{up,down}.d,
and at the same I have greatly changed them. What happens if they are not
removed is that both of them will be executed. They both start a process
in background (fetch and/or send mail). Whatever will be executed first
will block (by a lock file) the second, because it is likely that the
time span between them is short. The old scripts also depend on a conf file
which is obsolete as well (it is still there, because it is a conffile, but
not supported by debconf).
My worries are that I get lots of bug reports because the package does not
behave as expected by the users.
So why not chmod -x them in your postinst and pop up a debconf note that
explains the new situation. The scripts are not removed, they are simply
disabled. Also document this in your changelog and in README.Debian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Doesn't lintian accept overriding its build-depends-without-
On 23-Jun-2002 Shaul Karl wrote: As previously discussed here ( http://lists.debian.org/2002/debian-mentors-200202/msg00100.html ) I am trying to override lintian's build-depends-without-arch-dep error. Lintian's output line is: E: tkman source: build-depends-without-arch-dep I have tried to put in usr/share/lintian/overrides/tkman the following lines: build-depends-without-arch-dep tkman: build-depends-without-arch-dep tkman source: build-depends-without-arch-dep this is the line that would have worked, if overriding source errors was permitted. tkman: tkman source: build-depends-without-arch-dep However none was able to overrides lintian's error message. What am I doing wrong? nothing except trying to override something lintian does not know how to override (-: The better answer is lintian needs to be fixed to handle this somehow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian and statically link binaries
On 12-Jun-2002 Joey Hess wrote: Oliver Kurth wrote: Hello! I want to package cpuburn, this is a small collection of assembler prgrams to test CPUs (x86 only). lintian gives me these errors: oku@robin:~/debian/cpuburn-1.4$ lintian ../cpuburn_1.4-1_i386.deb E: cpuburn: statically-linked-binary ./usr/sbin/burnBX I belive that's simply a limitation of file, it cannot tell program statically linked with libc from a hand-crafted assembly program. I'd override it. basically. lintian's goal is to catch silly omissions, mistakes, oops, etc from maintainers. A statically linked file is almost always an accident. For the 20 or so packages that need statics we have overrides. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Priorities
On 18-Jun-2002 Jeff Bailey wrote: When perusing debian-devel recently, I noticed an email indicating that one of my packages, mailutils, has the wrong priority (Perhaps ones day I'll understand why people talk about bugs instead of simply filing them... *sigh*) So my question is, How are priority important and required selected? In this case mailutils conflicts with mailx and is not a 100% suitable replacement yet, so there's no worries. But, I'm planning on uploading GNU inetutils soon. These should certainly be priority: required/important on hurd-i386 - netkit doesn't build on anything other than GNU/Linux and has no intention of it. I'd also like to see Inetutils considered for being the default in a year or so (when we finish tightening it up) since it's intended to be compiled on many systems (so is suitable for GNU/Hurd and the BSD Port). debian policy manual, section 2.2. inetutils or mailutils sounds destined to live in 'optional' forever. our current setup does not allow for 'standard' in one and 'optional' in another without having two (or more) sources. P.S. great sig, I tracked down the original mail to have the surrounding comments. its funny, blackbox's workspaces are implemented in yet another way (-: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian and statically link binaries
On 12-Jun-2002 Joey Hess wrote: Oliver Kurth wrote: Hello! I want to package cpuburn, this is a small collection of assembler prgrams to test CPUs (x86 only). lintian gives me these errors: [EMAIL PROTECTED]:~/debian/cpuburn-1.4$ lintian ../cpuburn_1.4-1_i386.deb E: cpuburn: statically-linked-binary ./usr/sbin/burnBX I belive that's simply a limitation of file, it cannot tell program statically linked with libc from a hand-crafted assembly program. I'd override it. basically. lintian's goal is to catch silly omissions, mistakes, oops, etc from maintainers. A statically linked file is almost always an accident. For the 20 or so packages that need statics we have overrides. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Priorities
On 18-Jun-2002 Jeff Bailey wrote: When perusing debian-devel recently, I noticed an email indicating that one of my packages, mailutils, has the wrong priority (Perhaps ones day I'll understand why people talk about bugs instead of simply filing them... *sigh*) So my question is, How are priority important and required selected? In this case mailutils conflicts with mailx and is not a 100% suitable replacement yet, so there's no worries. But, I'm planning on uploading GNU inetutils soon. These should certainly be priority: required/important on hurd-i386 - netkit doesn't build on anything other than GNU/Linux and has no intention of it. I'd also like to see Inetutils considered for being the default in a year or so (when we finish tightening it up) since it's intended to be compiled on many systems (so is suitable for GNU/Hurd and the BSD Port). debian policy manual, section 2.2. inetutils or mailutils sounds destined to live in 'optional' forever. our current setup does not allow for 'standard' in one and 'optional' in another without having two (or more) sources. P.S. great sig, I tracked down the original mail to have the surrounding comments. its funny, blackbox's workspaces are implemented in yet another way (-: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to package conflicting libraries ?
On 10-Jun-2002 Eric Gentilini wrote: Hi, Considering a given library libfoo, which of another version supporting multithreading is available, called libfoo-mt. libfoo-mt offers all the functionnalities offered by libfoo and programs compiling with libfoo compile with libfoo-mt (binary versions linked with libfoo-mt won't run with libfoo and vice-versa). Should libfoo-mt be marked as creating a conflict with libfoo ? Or should it be sonamed libfoomt and depending executables linked with that name ? PS : more precisely, I'm talking about libmico and micomt for those who want to know :) this is exactly the situation qt is under, look at it (but not too hard your eyes might pop out and your head explode (-; ). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to package conflicting libraries ?
On 10-Jun-2002 Eric Gentilini wrote: Hi, Considering a given library libfoo, which of another version supporting multithreading is available, called libfoo-mt. libfoo-mt offers all the functionnalities offered by libfoo and programs compiling with libfoo compile with libfoo-mt (binary versions linked with libfoo-mt won't run with libfoo and vice-versa). Should libfoo-mt be marked as creating a conflict with libfoo ? Or should it be sonamed libfoomt and depending executables linked with that name ? PS : more precisely, I'm talking about libmico and micomt for those who want to know :) this is exactly the situation qt is under, look at it (but not too hard your eyes might pop out and your head explode (-; ). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for sponsor for Kopete
On 29-May-2002 Till Gerken wrote: Hi, I'd like to package Kopete for Debian. Since this would be my first package and I am not a Debian member yet, I'm looking for a sponsor to help me get started. When you have a package you have prepared from the latest sources, contact me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binary depends
Well, you could try running the program through strace, and then look at all the opened files (with the proper strace flag) and then run dpkg -S on them. Same as for autodetecting build depends. you still miss programs called from maintainer scripts (or any script for that matter). This is really a heuristic issue and it will never be right. Of course, this is the type of fun project just waiting to be hacked on (-: Come on Bob, scratch your own itch! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binary depends
On 24-May-2002 Matt Zimmerman wrote: On Fri, May 24, 2002 at 11:37:42AM -0500, Steve Langasek wrote: Sounds like a good enough heuristic to be worth implementing, if someone has the interest. Someone already had the interest, and implemented it: auto-apt. auto-apt only detects file not found and does a look up in the file list for the package which owns it. It is not of much help during the package build. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binary depends
On 25-May-2002 Junichi Uekawa wrote: On Fri, 24 May 2002 11:27:59 -0700 (PDT) Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: auto-apt only detects file not found and does a look up in the file list for the package which owns it. It is not of much help during the package build. It installs the package. if that mode is chosen, yes. It still does not help with maintainer scripts or a whole slew of other cases. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Binary depends
On 23-May-2002 Bob Hilliard wrote: I have just discovered (via a bug report) that dict and dictd depend on netbase. (dict and dictd communicate with each other using the TCP/IP protocol.) Since dictd has been in debian for over four years without declaring the dependency, this indicates that netbase is almost universally installed! :-) Is there any tool, comparable to dpkg-shlibs, to determine non-library dependencies? unfortuantely not because they are really hard to discover. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Library package naming
For shared libraries, I would use libijs{n} and libijs-dev, but ijs
does not yet have a stable ABI, and is not versioned properly as well
as being tiny, so I have just packaged it as a static library.
Would 'ijs-dev' be legal (as in publib-dev), or should I use
'libijs-dev' (or is this for shared libs only?).
think long term, will it become a shared lib? If so using ijs-dev now makes it
easier to ask for that package to die and libijs and libijs-dev to takes its
place later.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog and /usr/share/doc/package as a symlink
On 28-Apr-2002 Oohara Yuuma wrote: On Sat, 27 Apr 2002 10:01:29 -0700 (PDT), Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: Don't just split without good reason. I am planning to split xsolider into 3 packages because: * both raw X version and SDL version are available and only one of them is enough to play the game * I don't see any reason why each game engine should have its own copy of image data that is a good reason. Your initial email implied one binary and one data package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog and /usr/share/doc/package as a symlink
On 27-Apr-2002 Oohara Yuuma wrote: Suppose that a source package makes two .deb, package-data and package (which depends on package-data), and /usr/share/doc/package is a symlink to /usr/share/doc/package-data . Should package depend on exactly the same version of package-data? allows any version - changelog may be out of date if only package is upgraded depneds on the same version - forces the user to download huge package-data on each upgrade and as always you must ask yourself -- why am I splitting this package? Does it make sense for the user to only install one of them? Can they function out version sync? Since the user is likely to just be apt-get upgrading anyway, what chance is there that a version skew will occur? Don't just split without good reason. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog and /usr/share/doc/package as a symlink
On 27-Apr-2002 Junichi Uekawa wrote: Oohara Yuuma [EMAIL PROTECTED] cum veritate scripsit: Suppose that a source package makes two .deb, package-data and package (which depends on package-data), and /usr/share/doc/package is a symlink to /usr/share/doc/package-data . Should package depend on exactly the same version of package-data? Why do you have to make it a symlink at all ? By doing that you are distributing a .deb file which does not contain copyright information, etc. it is legal *IFF* the package depends on another package from the same source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog and /usr/share/doc/package as a symlink
On 27-Apr-2002 Oohara Yuuma wrote: Suppose that a source package makes two .deb, package-data and package (which depends on package-data), and /usr/share/doc/package is a symlink to /usr/share/doc/package-data . Should package depend on exactly the same version of package-data? allows any version - changelog may be out of date if only package is upgraded depneds on the same version - forces the user to download huge package-data on each upgrade and as always you must ask yourself -- why am I splitting this package? Does it make sense for the user to only install one of them? Can they function out version sync? Since the user is likely to just be apt-get upgrading anyway, what chance is there that a version skew will occur? Don't just split without good reason. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installman
On 13-Apr-2002 Joey Hess wrote: Roger Leigh wrote: install man pages that are 0 length files. If you send me your build tree I can try to debug it. Ah, thanks. Some of the manpages are (oddly) zero-length. I'll have to write some when I get time, if there are not any elsewhere. All right, the next version of debhelper (in about 9 days) will deal with this better (for some definitiions of better anyway -- I hope lintian whines about it.) if not submit the appropriate bugs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_installman
On 13-Apr-2002 Joey Hess wrote: Roger Leigh wrote: install man pages that are 0 length files. If you send me your build tree I can try to debug it. Ah, thanks. Some of the manpages are (oddly) zero-length. I'll have to write some when I get time, if there are not any elsewhere. All right, the next version of debhelper (in about 9 days) will deal with this better (for some definitiions of better anyway -- I hope lintian whines about it.) if not submit the appropriate bugs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packaging question
On 03-Apr-2002 David H. Askew wrote: Ok.. so i'm working on packages for jedit .. and I'm contemplating splitting the documentation into its own sepperate package. so there will be jedit jedit-doc or jedit-doc-html (which is prefered)? generally you specify html if there is another choice. background(for non-jedit users) : jedit has a built-in doc-browser which loads a startup page. I was thinking about replacing this page with something that says ... hey .. you need to install the jedit-doc package or something similar.. is this a reasonable solution? sounds sane. ..the documentation isn't that heavy .. but I'm of the opinion that it should be a seperate package... if for no other reason than I don't like to have unneaded docs installed on my system.. if I don't want them... Sure you may not need them. But how many users would? The main reason to split off doc packages is if they are really large or can be output in many formats and the user only really needs one of them. The docs are distributed in the same src package as the program, so if I make two packages, one for the docs and one for the binary.. won't the debian archive contain two identical versions of the source code when it is uploaded? .. this seams kinda bloated ... so I'm sure there is something I don't understand ... is this what multiple-binary packages are for? yes you want one upstream tarball - multiple (2) debian packages. You definately should NOT split the upstream source if you can avoid it. Remember, splitting the package means the user has to install the docs by hand. If they happen to need them when they do not have access to the deb (ISP outage, kid sister on the phone and can't use the modem, phone bill too high already this month, on a laptop in a cafe somewhere etc) they just have to make do. Who benefits from splitting the package? You? Extra work, one more package in the source. 20k less on your hard drive. The user? As hackers, we sometimes have to step back and analyse our desires for engineering beauty. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packaging question
On 03-Apr-2002 David H. Askew wrote: Ok.. so i'm working on packages for jedit .. and I'm contemplating splitting the documentation into its own sepperate package. so there will be jedit jedit-doc or jedit-doc-html (which is prefered)? generally you specify html if there is another choice. background(for non-jedit users) : jedit has a built-in doc-browser which loads a startup page. I was thinking about replacing this page with something that says ... hey .. you need to install the jedit-doc package or something similar.. is this a reasonable solution? sounds sane. ..the documentation isn't that heavy .. but I'm of the opinion that it should be a seperate package... if for no other reason than I don't like to have unneaded docs installed on my system.. if I don't want them... Sure you may not need them. But how many users would? The main reason to split off doc packages is if they are really large or can be output in many formats and the user only really needs one of them. The docs are distributed in the same src package as the program, so if I make two packages, one for the docs and one for the binary.. won't the debian archive contain two identical versions of the source code when it is uploaded? .. this seams kinda bloated ... so I'm sure there is something I don't understand ... is this what multiple-binary packages are for? yes you want one upstream tarball - multiple (2) debian packages. You definately should NOT split the upstream source if you can avoid it. Remember, splitting the package means the user has to install the docs by hand. If they happen to need them when they do not have access to the deb (ISP outage, kid sister on the phone and can't use the modem, phone bill too high already this month, on a laptop in a cafe somewhere etc) they just have to make do. Who benefits from splitting the package? You? Extra work, one more package in the source. 20k less on your hard drive. The user? As hackers, we sometimes have to step back and analyse our desires for engineering beauty. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
I thought the main problem was this strange combination - I removed it to
no avail, and fiddled with the line until I got the problem: I removed the
first dependency (${shlibs:Depends}), and it worked correctly.
I have always seen this thing in the dependencies, and I still don't know
what it means. Can anybody share some light on it?
${shlibs} is replaced by the output of dpkg-shlibdeps. debhelper should make a
call to this or you should. This is how the depends on things like libc and
what not get in the control file.
Basically, it runs ldd on your item and then tries to figure out what package
and version each item in the list came from and lists it in the depends.
My package blackbox says:
Depends: ${shlibs:Depends}
and the output is:
Depends: libc6 (= 2.2.4-4), libstdc++2.10-glibc2.2 (= 1:2.95.4-0.010810),
xlibs ( 4.1.0)
dh_shlibdeps is run in my rules file.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
