Packaging Barcode Writer in Pure PostScript
Hi,
I'm currently packaging the Barcode Writer in Pure PostScript project
that I have written. This is my first attempt at creating a source
package which I have created by following the Debian New Maintainers
Guide.
Would people please examine the package and tell me what problems
exist. You can view the files at
http://www.terryburton.co.uk/barcodewriter/files/debiansrc
Some additional questions:
The project has no dependancies. Is it safe to remove this line from
the control file?
Depends: ${shlibs:Depends}, ${misc:Depends}
The upstream project unpacks all files into a single directory and
does not provide a facility for installing the files into a distro's
file system hierarchy. For the Debian package I have created a
Makefile that accomplishes his via the install target. There is no
compilation necessary so I have created empty all and clean targets.
Could somebody verify that this is the correct way to handle such a
package.
Debian Policy mandates that programs have a manpage. Since this is a
PostScript resource (similar to a shared library) does this rule still
apply. If so then I'm not sure what the content of such a manpage
ought to be.
The project is platform independant as specified in the control file.
When I run dpkg-buildpackage -rfakeroot from within the project source
directory it creates a package for i386. Is this normal behaviour? How
to I create an all architectures binary package?
After I have got the source package into good shape, do you have any
advise on finding a package sponser? Any volunteers.
Thanks for the assistance.
Thanks,
Tez
Re: Packaging Barcode Writer in Pure PostScript
On Tue, Sep 06, 2005 at 09:53:51AM +0100, Terry Burton wrote:
> Hi,
Hello,
> Would people please examine the package and tell me what problems
> exist. You can view the files at
> http://www.terryburton.co.uk/barcodewriter/files/debiansrc
After a very brief look, I can only say I saw a lot of commented out lines in
rules.make. I guess they come from dh_make. There's no need to leave them
in, just remove them.
> Some additional questions:
>
> The project has no dependancies. Is it safe to remove this line from
> the control file?
> Depends: ${shlibs:Depends}, ${misc:Depends}
A follow-up to that question: ${misc:Depends} gives "undefined variable" (or
something) warnings on some of my packages. Should I remove them from those,
or is it good to leave them in in case something will be substituted in there
later? Where would the content come from anyway?
> The upstream project unpacks all files into a single directory and
> does not provide a facility for installing the files into a distro's
> file system hierarchy. For the Debian package I have created a
> Makefile that accomplishes his via the install target. There is no
> compilation necessary so I have created empty all and clean targets.
> Could somebody verify that this is the correct way to handle such a
> package.
Personally, I would just use debian/rules for that. There is a step to build
(which will be empty in this case) and one to install, which will be like
cp --parents files debian/tmp/somedir/.
> Debian Policy mandates that programs have a manpage. Since this is a
> PostScript resource (similar to a shared library) does this rule still
> apply. If so then I'm not sure what the content of such a manpage
> ought to be.
Policy mandates manpages for executables. This is not one of them, I guess.
However, it is good to create one anyway if the user can directly use the
file. That is, if it is only used by other programs (as is the case for a
shared library), there is no need for a manpage. If you expect the user to
use the files in the package directly, a man page is in order IMO. In it
should be a manual describing what the user could do with it. In other words,
after reading the man page, the user should be able to use the package.
> The project is platform independant as specified in the control file.
No, you specified "Architecture: any" in the control file, which means it is
portable to all platforms, in other words that it can be compiled on each of
them. "Architecture: all" means it's platform independant.
> After I have got the source package into good shape, do you have any
> advise on finding a package sponser? Any volunteers.
I'm not a DD yet, so I can't help you there.
Bye,
Bas Wijnen
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
Re: Packaging Barcode Writer in Pure PostScript
On 06-Sep-2005, Terry Burton wrote: > I'm currently packaging the Barcode Writer in Pure PostScript > project that I have written. Yay! I like this program, thanks. > Debian Policy mandates that programs have a manpage. Since this is a > PostScript resource (similar to a shared library) does this rule > still apply. If so then I'm not sure what the content of such a > manpage ought to be. The policy mentions manual pages here: http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1> "Each program, utility, and function should have an associated manual page included in the same package. It is suggested that all configuration files also have a manual page included as well. Manual pages for protocols and other auxiliary things are optional." By "program" and "utility", I understand that Policy refers to commands that can be given at a shell prompt. By "function", I understand that Policy refers to library functions. The Barcode Writer is a PostScript program, but is not a command that can be executed at a system shell prompt. I think it counts as pure data, and a manpage is "optional". I also think such a manpage wouldn't be much use. > After I have got the source package into good shape, do you have any > advise on finding a package sponser? Any volunteers. You're in the right place; sponsors will likely present themselves in response to this email on debian-mentors. -- \ "I got some new underwear the other day. Well, new to me." -- | `\ Emo Philips | _o__) | Ben Finney <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Packaging Barcode Writer in Pure PostScript
Hi, > After I have got the source package into good shape, do you have any > advise on finding a package sponser? Any volunteers. If you don't find a sponsor, have a read of womble's excellent debian-mentors FAQ[0] (recently updated) and add your sponsorship request to sponsors.debian.net so it doesn't get lost in history. 0. http://people.debian.org/~mpalmer/debian-mentors_FAQ.html -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
Hello all, I am trying to package qingy (qingy.sf.net) for which there are 2 RFPs - 309672 and 236706 - in BTS for a looong time. I have tried it on my system and seems ok, although there seems to be some kind of race condition in the code resulting in a deadlock if the user changes the tty back and forth freneticaly. That is an upsteam problem, but I have also some another problems: - if I add dh_shlibdeps to the build then I have a warning during the build of the package - something about misc libs not being defined and some nasty errors during installation, but the package installs and works, anyway; also lintian reports an unnecessary call to ld - if I remove dh_shlibdeps, then the package results in a cyclic dependency on itself, but the misc issue disappears; also the ld issue is gone - the compile generates a set of 3 libqingy* files; do I have to make a libqingy package, too? - there is a qingy file in etc/pam.d which is not copied in the package, although I added dh_installpam; the directory in the resulting package is empty and the file in question is not anywhere in the package; - the application is licensed under the GPL, but the documentation is GFDL; I saw that the upstream authors say "free programs need free documentation", thus I feel they (only 2 of them) would agree to changing the documentation license; what do you suggest I should do? Can anybody help me? This is my first package* so please bear with me as I might not know what I am talking about sometimes**. * I have another ITP, but is quite hard for a first package, so I postponed it, for now. ** I was under the impression I took the source package with myself, from home to work. -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein
Re: Packaging Barcode Writer in Pure PostScript
Terry Burton <[EMAIL PROTECTED]> writes:
> Would people please examine the package and tell me what problems
> exist. You can view the files at
> http://www.terryburton.co.uk/barcodewriter/files/debiansrc
The debian/rules is very bloated, please remove everything which is not
needed and not mandated by Policy (the CFLAGS bits, for example)
> The project has no dependancies. Is it safe to remove this line from
> the control file?
> Depends: ${shlibs:Depends}, ${misc:Depends}
What do you need to use this PostScript thingy? There is no Debian
package without a Depends line, as you always need something else to
properly use it.
> The upstream project unpacks all files into a single directory and
> does not provide a facility for installing the files into a distro's
> file system hierarchy. For the Debian package I have created a
> Makefile that accomplishes his via the install target.
You don't need that, you can use dh_install in debian/rules.
> Debian Policy mandates that programs have a manpage. Since this is a
> PostScript resource (similar to a shared library) does this rule still
> apply. If so then I'm not sure what the content of such a manpage
> ought to be.
There should be some documentation, not necessarily as man page.
> The project is platform independant as specified in the control file.
No, you didn't. Please look up the difference between Arch: any and
Arch: all.
Marc
--
BOFH #348:
We're on Token Ring, and it looks like the token got loose.
pgp0x1KbCJXVM.pgp
Description: PGP signature
Re: Packaging Barcode Writer in Pure PostScript
Hi,
I've removed the Makefile and made use of dh_install. I've also
slimmed the debian/rules file by removing the commented lines and dh_*
rules that seem redundant, as suggested. I would appreciate it if
someone could offer any assistance in further tidying this up.
It is now also building for Architecture: all, but linda gives be the
following message:
W: libpostscriptbarcode; File /usr/lib/libpostscriptbarcode/barcode.ps
contained in /usr/lib of Architecture: all package.
Instructions and example uses for using the library are given on the
project homepage at http://www.terryburton.co.uk/barcodewriter as
stated in the README file.
Please could people review the changes that I've now made. Files are
at http://www.terryburton.co.uk/barcodewriter/files/debiansrc.
Many thanks,
Tez
On 06/09/05, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:
> Terry Burton <[EMAIL PROTECTED]> writes:
> > Would people please examine the package and tell me what problems
> > exist. You can view the files at
> > http://www.terryburton.co.uk/barcodewriter/files/debiansrc
>
> The debian/rules is very bloated, please remove everything which is not
> needed and not mandated by Policy (the CFLAGS bits, for example)
>
> > The project has no dependancies. Is it safe to remove this line from
> > the control file?
> > Depends: ${shlibs:Depends}, ${misc:Depends}
>
> What do you need to use this PostScript thingy? There is no Debian
> package without a Depends line, as you always need something else to
> properly use it.
>
> > The upstream project unpacks all files into a single directory and
> > does not provide a facility for installing the files into a distro's
> > file system hierarchy. For the Debian package I have created a
> > Makefile that accomplishes his via the install target.
>
> You don't need that, you can use dh_install in debian/rules.
>
> > Debian Policy mandates that programs have a manpage. Since this is a
> > PostScript resource (similar to a shared library) does this rule still
> > apply. If so then I'm not sure what the content of such a manpage
> > ought to be.
>
> There should be some documentation, not necessarily as man page.
>
> > The project is platform independant as specified in the control file.
>
> No, you didn't. Please look up the difference between Arch: any and
> Arch: all.
>
> Marc
> --
> BOFH #348:
> We're on Token Ring, and it looks like the token got loose.
>
>
>
Re: Packaging Barcode Writer in Pure PostScript
Hi, > Hi, > > I've removed the Makefile and made use of dh_install. I've also > slimmed the debian/rules file by removing the commented lines and dh_* > rules that seem redundant, as suggested. I would appreciate it if > someone could offer any assistance in further tidying this up. Generally, you just put once dh_install resp. dh_installdocs in your rules file and create files debian/install resp. debian/docs (or debian/.install etc.), it's easier to maintain (man pages explain the format of these files). You can remove CHANGES from debian/docs, it's already taken care by dh_installchangelogs (and/or have a look at the option --keep of this command). > > It is now also building for Architecture: all, but linda gives be the > following message: > > W: libpostscriptbarcode; File /usr/lib/libpostscriptbarcode/barcode.ps > contained in /usr/lib of Architecture: all package. Architecture independent files should be installed under /usr/share and not /usr/lib, i.e. /usr/share/libpostscriptbarcode/barcode.ps Cheers, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging Barcode Writer in Pure PostScript
Okay, next round :-) Please recheck files at http://www.terryburton.co.uk/barcodewriter/files/debiansrc. Target is now /usr/share/libpostscriptbarcode, not /usr/lib/libpostscriptbarcode. Created debian/install file to simplify debian/rules. Added -X option to dh_installdocs to prevent compression of barcode_with_sample.ps file. Any further advise regarding the package would be appreciated. Many thanks, Tez On 06/09/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > > Hi, > > > > I've removed the Makefile and made use of dh_install. I've also > > slimmed the debian/rules file by removing the commented lines and dh_* > > rules that seem redundant, as suggested. I would appreciate it if > > someone could offer any assistance in further tidying this up. > Generally, you just put once dh_install resp. dh_installdocs in your rules > file and create files debian/install resp. debian/docs (or > debian/.install etc.), it's easier to maintain (man pages > explain the format of these files). > You can remove CHANGES from debian/docs, it's already taken care by > dh_installchangelogs (and/or have a look at the option --keep of this > command). > > > > It is now also building for Architecture: all, but linda gives be the > > following message: > > > > W: libpostscriptbarcode; File /usr/lib/libpostscriptbarcode/barcode.ps > > contained in /usr/lib of Architecture: all package. > Architecture independent files should be installed under /usr/share and > not /usr/lib, i.e. /usr/share/libpostscriptbarcode/barcode.ps > > Cheers, Eric > > -- > Eric de France, d'Allemagne et de Navarre >
Re: Problem with one package that use php License
Hi, As I understand, that's php-xml-util, php-xml-serializer (http://pear.php.net/package/XML_Serializer/), php-soap and php-cache. Yes Which other package? Which horde3 version? php-services-weather require these packages,, and horde3 require this one. Horde3 run whitout php-services-weather, but If one person try to add module Services_Weather in Horde he will receive an error message. [] Jose Carlos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
On Tue, Sep 06, 2005 at 01:10:11PM +0300, Eddy Petri?or wrote: > Hello all, Good morning, > - if I add dh_shlibdeps to the build then I have a warning during the > build of the package - something about misc libs not being defined and > some nasty errors during installation, but the package installs and > works, anyway; also lintian reports an unnecessary call to ld > - if I remove dh_shlibdeps, then the package results in a cyclic > dependency on itself, but the misc issue disappears; also the ld issue > is gone Did you try using the -l option to dh_shlibdeps? I think this is necessary to allow it to search your package directory for libraries. My understanding is that the shlibs file is what allows runtime dependencies to be handled nicely. Check /var/lib/dpkg/info/*.shlibs; all the libraries you have installed provide a file which allow for a mapping between a given dependency (the output of objdump -p |grep -w NEEDED) and a given package name. > - the compile generates a set of 3 libqingy* files; do I have to make > a libqingy package, too? It seems that these are probably not meant to be used by other applications, correct? Are the 3 files .a, .so, and .so.0, or are there 3 libquingy-$foo.so files, for 3 different values of $foo? My understanding is that you should not provide a separate library package if the libraries are just internal to the program, and are not meant to be used by others. If they _are_ meant to be used by others (other developers, and other packages, potentially), then my understanding is that you should provide a separate libquingy package (and a libquingy-dev which contains just the libquingy.a, the libquingy.so => libquingy.so.0 symlink for compilation, and the quingy.h header). Are there multiple binaries in your package? If not, then you should probably just link the library statically into the single binary, which resolve the whole issue anyway. There was a -mentors thread about this about 6 months ago. Could someone else comment on when a separate shared library package should be used? Could someone else also comment on how applications should deal with shared libraries which are not intended to be used by other programs? One possibility is to put the libraries into /usr/lib/quingy/, and make /usr/bin/ (/bin/?) quingy a #!/bin/sh script which simply sets LD_LIBRARY_PATH=/usr/lib/quingy and exec's /usr/lib/quingy/quingy, which would be the ELF binary itself. What you probably want to avoid is using the linker's RPATH setting to do the same. I tried it once myself, and I can confirm that rpath is highly inflexible. > - there is a qingy file in etc/pam.d which is not copied in the > package, although I added dh_installpam; the directory in the > resulting package is empty and the file in question is not anywhere in > the package; Do you have a ./debian/quingy.pam which lists the file? It seems that this is a special-case way of adding it as a conffile. Make sure that a conffile is actually what you want (I think it probably is). > - the application is licensed under the GPL, but the documentation is > GFDL; I saw that the upstream authors say "free programs need free > documentation", thus I feel they (only 2 of them) would agree to > changing the documentation license; what do you suggest I should do? Contact them and explain your position, if any, or provide pointers to Debian's take on the issue. Manoj has one such statement, and -legal surely has many more. Maybe you could suggest a dual license of the documentation? > ** I was under the impression I took the source package with myself, > from home to work. Huh? The "source package" is a thing defined as the .orig.tar.gz, the .diff.gz, and the .dsc file. It gets upload to a machine somewhere such that people (with the appropriates Sources.gz file, and sources.list entry) can apt-get source quingy. It is also what allows the Debian buildds to compile the package for the other architectures, and what satisfies, for example, the GPL's requirement that source be made available alongside the compiled binaries. I don't understand your last comment, or how it relates to anything else:) Greetings, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
Justin Pryzby <[EMAIL PROTECTED]> wrote: > Could someone else also comment on how applications should deal with > shared libraries which are not intended to be used by other programs? If they aren't used by other programs, there's no need to produce a library. Perhaps it's convienient to create static libraries during compilation and link against these, but shared libraries are of no use. Note that I wrote "if they aren't used by other programs". I didn't write "if they are not intended to be used", this is a different thing. If you have code in your project that fits other people's needs, they are going to use it. If there is no shared library, they'll just copy the code. Don't let that happen. xpdf has let this happen, and it makes up a medium-sized security nightmare: Everytime a security bug pops up in xpdf (and it does frequently), a couple of packages which come with their own particular version of that code have to be - checked whether that version is vulnerable - checked whether in that version the patch for current xpdf is sufficient to fix the issue - recompiled So it doesn't hurt to prepare your software for being a shared libray, and telling people that they should request that instead of copying your code. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Packaging Barcode Writer in Pure PostScript
Hi, sorry for this, but I think another round might be required: 1. move sample.ps, barcode_with_sample.ps, docs/* from debian/install to debian/docs. 2. I think you should just remove the Depends line (as far as I understand the thing you could just "cat barcode_with_sample.ps > /dev/lp0" and it would bring something to the user). 3. the documentation under docs/* is always the same in different formats, I understand that the correct way to do this would be to package only the source of this documentation (TeX or whatever) and generate the different formats on-the-fly during packaging. (but someone else might want to confirm on this last one before you take the hassle of doing this). Cheers, Eric PS: more as a joke you could rename your package to libbarcodewriter-ps in order to align the name with libwhatever-perl or libwhatever-java :-> -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging Barcode Writer in Pure PostScript
Hi, Thanks for all of your assistance Eric. New files available at http://www.terryburton.co.uk/barcodewriter/files/debiansrc. Documentation files moved from debian/install to debian/docs. Depends removed. I would prefer not to have to regenerate the documentation from TeX for the timebeing since it relies on TeX modules that are not yet part of Debian. Hopefully future Debian releases of the PSTricks packages will remedy this situation making this a sensible option. It would also seem a bit overkill to have such a simple library depend on something as large as LaTeX. Many thanks, Tez PS: I don't think I'll bother with another name change. I've just filed an ITP report for the project as libpostscriptbarcode against an existing RFP for postscriptbarcode. I'm sure that will ruffle a few DDs feathers, but changing project name again may make some of them fall off their perch! No offence intended... :-) On 06/09/05, Eric Lavarde - Debian <[EMAIL PROTECTED]> wrote: > Hi, > > sorry for this, but I think another round might be required: > 1. move sample.ps, barcode_with_sample.ps, docs/* from debian/install to > debian/docs. > 2. I think you should just remove the Depends line (as far as I understand > the thing you could just "cat barcode_with_sample.ps > /dev/lp0" and it > would bring something to the user). > 3. the documentation under docs/* is always the same in different formats, > I understand that the correct way to do this would be to package only the > source of this documentation (TeX or whatever) and generate the different > formats on-the-fly during packaging. > (but someone else might want to confirm on this last one before you take > the hassle of doing this). > > Cheers, Eric > > PS: more as a joke you could rename your package to libbarcodewriter-ps in > order to align the name with libwhatever-perl or libwhatever-java :-> > > -- > Eric de France, d'Allemagne et de Navarre >
Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
On Tue, Sep 06, 2005 at 05:56:54PM +0200, Frank K?ster wrote: > Justin Pryzby <[EMAIL PROTECTED]> wrote: > > > Could someone else also comment on how applications should deal with > > shared libraries which are not intended to be used by other programs? > > If they aren't used by other programs, there's no need to produce a > library. Perhaps it's convienient to create static libraries during > compilation and link against these, but shared libraries are of no use. What if there are many binaries (10s of them) in your package, and you want to use shared libs purely for resource efficiency (disk and memory)? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging Barcode Writer in Pure PostScript
Marc 'HE' Brockschmidt wrote on 06/09/2005 12:29: > There is no Debian package without a Depends line, > as you always need something else to properly use it. This is not true. For an example look at busybox-static gcc-4.0-base or libc6: aptitude show busybox-static gcc-4.0-base libc6 cu, sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
Justin Pryzby <[EMAIL PROTECTED]> wrote: > On Tue, Sep 06, 2005 at 05:56:54PM +0200, Frank K?ster wrote: >> Justin Pryzby <[EMAIL PROTECTED]> wrote: >> >> > Could someone else also comment on how applications should deal with >> > shared libraries which are not intended to be used by other programs? >> >> If they aren't used by other programs, there's no need to produce a >> library. Perhaps it's convienient to create static libraries during >> compilation and link against these, but shared libraries are of no use. > What if there are many binaries (10s of them) in your package, and you > want to use shared libs purely for resource efficiency (disk and > memory)? You're right, that's an other reason for a shared library. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: pkg-config
Steve Langasek <[EMAIL PROTECTED]> wrote: > Symbol versions are transparent to the application, but when present > at build time the linker binds references to that symbol to the > specified symbol version -- this allows the runtime linker to > distinguish between two different functions with the same name but > different implementations. I think I understand the semantics of ELF versioned symbols, but I don't really understand why they are supposed to be useful. For example, glibc has two versions of "chown", GLIBC_2.1 (the default) and GLIBC_2.0. What is supposed to be the difference between them? Why is it useful that which version of "chown" you get at run time depends on the version of libc.so that was present when the executable was built? I don't think I've seen documentation for versioned symbols that explains their motivation and exact semantics. Is there any? Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
On Tue, Sep 06, 2005 at 07:18:17PM +0200, Frank K?ster wrote:
> Justin Pryzby <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Sep 06, 2005 at 05:56:54PM +0200, Frank K?ster wrote:
> >> Justin Pryzby <[EMAIL PROTECTED]> wrote:
> >>
> >> > Could someone else also comment on how applications should deal with
> >> > shared libraries which are not intended to be used by other programs?
> >>
> >> If they aren't used by other programs, there's no need to produce a
> >> library. Perhaps it's convienient to create static libraries during
> >> compilation and link against these, but shared libraries are of no use.
> > What if there are many binaries (10s of them) in your package, and you
> > want to use shared libs purely for resource efficiency (disk and
> > memory)?
>
> You're right, that's an other reason for a shared library.
In which case, should the shared libraries go into a separate package?
What should they be named (filenames and sonames)? Should they be in
/usr/lib/ or in /usr/lib/pkg/? If /u/l/pkg/, what is the recommended
way of linking them (LD_LIBRARY_PATH, maybe, but surely not rpath)?
Is it still okay if the binary interface is not at all stable, or
guaranteed to be compatible between versions? I'm thinking of the
case where a Debian packager adds shared lib support for better
resource efficiency, but upstream doesn't implement it, and interfaces
change at potentially every new release. Is it sufficient (if the
libs are in a separate package) to have the libs and the binaries both
Depends: pkg-{libs,bin} (=${Source-Version})?
It seem to me that there is no reason to requires libs to be in a
separate package, though it might be convenient to make this division,
but probably no deeper reason, correct? For a multiple-binary
package, it could be used as one of the arch-dep packages, if the
indep packages are significanly large to warrent the split.
Thanks,
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging Barcode Writer in Pure PostScript
Marc 'HE' Brockschmidt wrote: > There is no Debian > package without a Depends line, as you always need something else to > properly use it. Actually, there are over 1500 of them. Some packages survive with the Essentials :) $ grep-dctrl -c -FDepends -e '^$' \ >/var/lib/apt/lists/ftp.jyu.fi_debian_dists_sid_main_binary-i386_Packages 1537 Many of them do declare a Recommends or a Suggests, though... $ grep-dctrl -c -FDepends -e '^$' -a -FRecommends -e '^$' \ > -a -FSuggests -e '^$' \ >/var/lib/apt/lists/ftp.jyu.fi_debian_dists_sid_main_binary-i386_Packages 705 ... but many don't. :) -- Antti-Juhani signature.asc Description: OpenPGP digital signature
Re: pkg-config
On Mon, 2005-09-05 at 21:31 +0100, Mark Seaborn wrote: > Steve Langasek <[EMAIL PROTECTED]> wrote: [] > I think I understand the semantics of ELF versioned symbols, but I > don't really understand why they are supposed to be useful. > > For example, glibc has two versions of "chown", GLIBC_2.1 (the > default) and GLIBC_2.0. What is supposed to be the difference between > them? Why is it useful that which version of "chown" you get at run > time depends on the version of libc.so that was present when the > executable was built? (a) The interface may be different -- core dump or worse if you use the wrong symbol. (b) Even if the ABI is the same, the semantics may not be. Current example: libstdc++ .. :) -- John Skaller signature.asc Description: This is a digitally signed message part
[RFS] grace6: An XY plotting tool
Hello, I want to adopt grace6[1]. [1] http://bugs.debian.org/307358 I rebuild grace6[2], lintian and linda clean. I have upload it to mentors.debian.net[3]. [2] attachment: grace6_5.99.0+final-7_i386.changes [3] http://mentors.debian.net/debian/pool/main/g/grace6/ maybe you also like to look at the debdiff result, i add it in attachment.[4] [4] attachment: debdiff.log Thanks. -- Li Daobing -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 7 Sep 2005 06:01:13 +0800 Source: grace6 Binary: grace6 Architecture: source i386 Version: 5.99.0+final-7 Distribution: unstable Urgency: low Maintainer: LI Daobing <[EMAIL PROTECTED]> Changed-By: LI Daobing <[EMAIL PROTECTED]> Description: grace6 - An XY plotting tool Closes: 307358 Changes: grace6 (5.99.0+final-7) unstable; urgency=low . * New maintainer, closes: #307358 * bump Standards-Version to 3.6.2 * rebuild to depends on libplot2c2 * do not install files into /usr/X11R6 * debian/copyright: new fsf address * debian/menu: fix quote * debian/doc-base: fix doc directory Files: 4f5467836b2a3da5c43faec3ad392acb 773 math optional grace6_5.99.0+final-7.dsc 0f2df65922fc2d11d02a9b4bcc694e30 2633881 math optional grace6_5.99.0+final.orig.tar.gz 6e28c6a73ab20ed3049df757cd12ebbf 67018 math optional grace6_5.99.0+final-7.diff.gz 447ca76d0759d043a9b59c03801490bc 1143626 math optional grace6_5.99.0+final-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDHhwh5TUK4GCH0vgRAp0/AJ9infbGNjrO3+xTLK7eTablBvQIFACffTms bqEdZVRenXXjaJMFcEbWoEk= =Xdk5 -END PGP SIGNATURE- diff -u grace6-5.99.0+final/debian/control grace6-5.99.0+final/debian/control --- grace6-5.99.0+final/debian/control +++ grace6-5.99.0+final/debian/control @@ -1,8 +1,8 @@ Source: grace6 Section: math Priority: optional -Maintainer: Torsten Werner <[EMAIL PROTECTED]> -Standards-Version: 3.6.1 +Maintainer: LI Daobing <[EMAIL PROTECTED]> +Standards-Version: 3.6.2 Build-Depends: cdbs, debhelper (>= 4.1.0), lesstif2-dev, libxpm-dev, fftw-dev, libjpeg-dev, libpng-dev, netcdfg-dev, g77 | fortran77-compiler, xmhtml1-dev, libt1-dev, defoma, libexpat1-dev, libxmu-dev, linuxdoc-tools, libplot-dev Package: grace6 diff -u grace6-5.99.0+final/debian/changelog grace6-5.99.0+final/debian/changelog --- grace6-5.99.0+final/debian/changelog +++ grace6-5.99.0+final/debian/changelog @@ -1,3 +1,15 @@ +grace6 (5.99.0+final-7) unstable; urgency=low + + * New maintainer, closes: #307358 + * bump Standards-Version to 3.6.2 + * rebuild to depends on libplot2c2 + * do not install files into /usr/X11R6 + * debian/copyright: new fsf address + * debian/menu: fix quote + * debian/doc-base: fix doc directory + + -- LI Daobing <[EMAIL PROTECTED]> Wed, 7 Sep 2005 06:01:13 +0800 + grace6 (5.99.0+final-6) unstable; urgency=low * removed debian/postrm, closes: #314923 diff -u grace6-5.99.0+final/debian/rules grace6-5.99.0+final/debian/rules --- grace6-5.99.0+final/debian/rules +++ grace6-5.99.0+final/debian/rules @@ -13,8 +13,8 @@ mv debian/grace6/usr/share/grace/doc/*.1 \ debian/grace6/usr/share/man/man1/ $(RM) debian/grace6/usr/share/man/man1/xmgrace.1* - ln -s ../../../share/man/man1/grace.1.gz \ - debian/grace6/usr/X11R6/man/man1/xmgrace.1x.gz + ln -s grace.1.gz \ + debian/grace6/usr/share/man/man1/xmgrace.1x.gz $(RM) debian/grace6/usr/share/grace/fonts/type1/* \ debian/grace6/usr/share/grace/fonts/FontDataBase dh_installdefoma diff -u grace6-5.99.0+final/debian/dirs grace6-5.99.0+final/debian/dirs --- grace6-5.99.0+final/debian/dirs +++ grace6-5.99.0+final/debian/dirs @@ -3,4 +3,2 @@ -usr/X11R6/bin usr/share/doc/grace usr/share/man/man1 -usr/X11R6/man/man1 diff -u grace6-5.99.0+final/debian/menu grace6-5.99.0+final/debian/menu --- grace6-5.99.0+final/debian/menu +++ grace6-5.99.0+final/debian/menu @@ -1,5 +1,5 @@ ?package(grace6):\ - needs=X11\ - section=Apps/Math\ + needs="X11"\ + section="Apps/Math"\ title="Grace6"\ command="/usr/bin/xmgrace" diff -u grace6-5.99.0+final/debian/copyright grace6-5.99.0+final/debian/copyright --- grace6-5.99.0+final/debian/copyright +++ grace6-5.99.0+final/debian/copyright @@ -28,7 +28,7 @@ You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software -Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. On Debian GNU/Linux systems, the complete text of the GNU General diff -u grace6-5.99.0+final/debian/doc-base grace6-5.99.0+final/debian/doc-base --- grace6-5.99.0+final/debian/doc-base +++ grace6-5.99.0+final/debian/doc-base @@ -13,4 +13,4 @@ Format: HTML -Index: /usr/share/doc/grace/index.html -Files: /usr/share/doc/grace/*.html +Index: /usr/share/doc/grace6/index.html +Files: /usr/share/doc/grace6/*.html si
Re: Packaging Barcode Writer in Pure PostScript
I would prefer not to have to regenerate the documentation from TeX for the timebeing since it relies on TeX modules that are not yet part of Debian. Hopefully future Debian releases of the PSTricks packages will remedy this situation making this a sensible option. It would also seem a bit overkill to have such a simple library depend on something as large as LaTeX. Um that would not be a depends, but rather a build-depends. You should not worry about the size of build depends. Odds are anybody building packages will have LaTeX installed. Epecially true, since it make absolutely no sense for anybody to be recomping this particular package except you and your sponsor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] grace6: An XY plotting tool
Package: grace6 Severity: grave Version: 5.99.0+final-7 Christoph Berg schrieb: > Re: Li Daobing in <[EMAIL PROTECTED]> > >>I want to adopt grace6[1]. >> >>[1] http://bugs.debian.org/307358 >> >>I rebuild grace6[2], lintian and linda clean. I have upload it to >>mentors.debian.net[3]. > > > Hi, > > the package looks fine. Uploaded. > > A minor nit: update the maintainer name in debian/copyright for the > next upload. > > Christoph Hello, DO NOT DO THAT AGAIN! RFH does not mean, that the package is not maintained. You should have coordinated the upload with the current maintainer - at least the ITA mail should be send some days/weeks *before* the upload. Ionut is the future maintainer who has coordinated with me. Ionut, please send your own ITA mail to the bug report mentioned above. We will discuss privately how to fix the problem. Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] grace6: An XY plotting tool
Torsten Werner wrote: Package: grace6 > Severity: grave > Version: 5.99.0+final-7 > > Christoph Berg schrieb: > >>Re: Li Daobing in <[EMAIL PROTECTED]> >> >>>I want to adopt grace6[1]. >>> >>>[1] http://bugs.debian.org/307358 >>> >>>I rebuild grace6[2], lintian and linda clean. I have upload it to >>>mentors.debian.net[3]. >> >> >>Hi, >> >>the package looks fine. Uploaded. >> >>A minor nit: update the maintainer name in debian/copyright for the >>next upload. >> >>Christoph > > > Hello, > > > DO NOT DO THAT AGAIN! > > RFH does not mean, that the package is not maintained. You should have > coordinated the upload with the current maintainer - at least the ITA > mail should be send some days/weeks *before* the upload. > > Ionut is the future maintainer who has coordinated with me. Ionut, > please send your own ITA mail to the bug report mentioned above. We will > discuss privately how to fix the problem. > First, that's a RFA, not RFH[1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307358 I think i am following the directive in [2]. And I am sorry that i am not familiar with the polite/rule you mentioned here. maybe you should submit a patch to improve this directive. [2] http://www.nl.debian.org/devel/wnpp/#l3 RFA If you are going to adopt a package, retitle its bug to replace ‘RFA’ with ‘ITA’, in order for other people to know the package is being adopted and to prevent its automatic removal from the archive, and set yourself as the owner of the bug. To actually adopt the package, upload it with your name in its Maintainer: field, and close this bug once the package has been installed. Anyway, you or Ionut can maintain this package. I don't care. Thanks. -- Li Daobing signature.asc Description: OpenPGP digital signature
