Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Tollef Fog Heen]

]] Tourneur Henry-Nicolas 

| * License : No license, only a copyright file

Surely that makes it illegal for us to distribute?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: multiarch and pkg-config

[Goswin von Brederlow]

Tollef Fog Heen  writes:

> ]] Simon McVittie 
>
> | `pkg-config --debug 2>&1 | grep i486` (on my i386) reveals that pkg-config
> | already looks in /usr/lib/pkgconfig/i486-linux-gnu; perhaps it could be made
> | to search /usr/lib/TRIPLET/pkgconfig too (hackish version:
> | /usr/lib/pkgconfig/TRIPLET could be a symlink there, on Debian).
>
> Yeah, I should probably change that around.  It's just a configure
> option, and given I don't believe anybody uses the triplet dir today,
> I'll probably just move it.

Seems simpler for sources as then setting libdir will do the right thing
already.

But how would -dev packages signal that they need support for this? They
do not depend on pkg-config as they are usable without. Should they
Breaks: pkg-config (<< ver)? Seems too strong.

> | However, this would also require that pkg-config itself was multiarch or
> | otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config,
> | like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); until
> | then, it's not useful for pkg-config-using libraries to be multiarch (if
> | I have i386 and amd64 versions of libdbus-1-dev, but only the one whose
> | architecture matches my version of pkg-config actually works, then I might
> | as well uninstall the other version of libdbus-1-dev).
> | 
> | I'd be interested to hear from Tollef what the plan is regarding pkg-config
> | and multiarch.
>
> I discussed this with Loïc Minier during UDS in Dallas and we did at
> least talk about using AC_CHECK_TOOL in pkg.m4.  I'd then need to
> implement some magic in pkg-config which feels a bit hackish, but which
> I could live with.  If somebody has feedback on the preferred way, I'm
> open to suggestions.

There already seems to be a check in place at least in some
sources. e.g cross building libxtst for arm:

http://www.emdebian.org/buildd/?log=libxtst-arm-1216068648.log&pkg=libxtst

| checking for arm-linux-gnu-pkg-config... no
| checking for pkg-config... /usr/bin/pkg-config
| configure: WARNING: In the future, Autoconf will not detect cross-tools
| whose name does not start with the host triplet.  If you think this
| configuration is useful to you, please write to autoc...@gnu.org.
| checking pkg-config is at least version 0.9.0... yes


> | In the meantime, from the point of view of the multiarch cabal, which of 
> these
> | is most correct?
> | 
> | * pkg-config'd libraries should not be multiarch until pkg-config supports 
> it,
> |   but the .a, .so should go in /usr/lib/TRIPLET as soon as possible
> |
> | * pkg-config'd libraries should not be multiarch until pkg-config supports 
> it,
> |   and until then they should ensure that the .a, .so stay in /usr/lib
> | 
> | * pkg-config'd libraries may do whichever of those is most straightforward
>
> If we want to support multiarch compilation, this sounds ok to me.  I'm
> personally not convinced by the point of doing it.  Though.

We probably don't want multiarch compilation as such but cross
compilation is a huge benfit for many people and multiarch dev packages
would make it possible to cross compile without having to set a sysroot
and without mangling packages during unpacking.

It also makes sense to compile sources with everything in the triplet
dir. No point having the *.so link or .pc files in different libdirs. It
is probably harder to not multiarchify the -dev packages as well.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian policy update (3.8.4.0)

[Goswin von Brederlow]

Tollef Fog Heen  writes:

> ]] Simon McVittie 
>
> | In the meantime, is there consensus that shuffling the development files 
> into
> | /usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
> | appropriate for -dev packages where all the arch-dependent files are in
> | arch-specific directories? I'd rather not break future work if -dev packages
> | aren't really settled yet.
>
> while it probably doesn't hurt, it's not been specified yet.
> Personally, I'd rather see us get the necessary changes to support
> running multiarch binaries in place before starting to move development
> libraries.
>
> [...]
>
> | > Architecture dependent header files belong under
> | > 
> | > /usr/include/triplet/
> | 
> | Is there consensus that that's the right place? I don't see any mention on
> | , which is the nearest I've seen to
> | a canonical description of the current state of multiarch (no pun intended).
>
> It's the only place that has been discussed, but again, the spec is for
> running multiarchified binaries, not compiling against them.  I wouldn't
> upload packages containing includes in triplet directories yet.

Support for /usr/include/triplet/ is in oldstable and stable.
And it is already being used:

% zgrep usr/include/x86_64-linux-gnu Contents-amd64.gz  
usr/include/x86_64-linux-gnu/ffi.h   libdevel/libffi-dev
usr/include/x86_64-linux-gnu/ffitarget.h libdevel/libffi-dev

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Guus Sliepen]

On Wed, Feb 03, 2010 at 10:37:08AM +0100, Tollef Fog Heen wrote:

> ]] Tourneur Henry-Nicolas 
> 
> | * License : No license, only a copyright file
> 
> Surely that makes it illegal for us to distribute?

Actually, it does have a license, which is in the COPYING file and at the top
of all the source code files:

   Permission to use, copy, modify, and distribute this software for
   any purpose and without fee is hereby granted, provided that this
   copyright and permission notice appear on all copies of the
   software and supporting documentation, the name of Cisco Systems,
   Inc. not be used in advertising or publicity pertaining to
   distribution of the program without specific prior permission, and
   notice be given in supporting documentation that modification,
   copying and distribution is by permission of Cisco Systems, Inc.

I think this can be distributed in the non-free section?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Henry-Nicolas Tourneur]

"Tollef Fog Heen"  Ecrivait:
> ]] Tourneur Henry-Nicolas 
> 
> | * License : No license, only a copyright file
> 
> Surely that makes it illegal for us to distribute?
> 
> -- 
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
> 
> 
> 
Yeah but what Craig Small said on mentors is that looks very much like a MIT
license - see COPYING file.
His mail is here :
http://lists.debian.org/debian-mentors/2010/02/msg00027.html


So it's more some kind of errors from my side because that wasn't very
clear.
Should I update this bug to put MIT-like as license ?

TIA.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Guus Sliepen]

On Wed, Feb 03, 2010 at 11:06:28AM +0100, Henry-Nicolas Tourneur wrote:

> > | * License : No license, only a copyright file
> > 
> > Surely that makes it illegal for us to distribute?
> > 
> Yeah but what Craig Small said on mentors is that looks very much like a MIT
> license - see COPYING file.
> His mail is here :
> http://lists.debian.org/debian-mentors/2010/02/msg00027.html

But, that's still a license. But look carefully, it says "without fee" in the
license. I don't know if that means "you can use it without paying anyone" or
"you can only redistribute it if you don't charge anyone".

> So it's more some kind of errors from my side because that wasn't very
> clear.
> Should I update this bug to put MIT-like as license ?

It's better to include the whole license if it isn't exactly equal to a
standard license.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Debian policy update (3.8.4.0)

[Goswin von Brederlow]

Simon McVittie  writes:

> Steve Langasek wrote:
>> On Mon, Feb 01, 2010 at 11:17:19PM +, Simon McVittie wrote:
>> > In the meantime, is there consensus that shuffling the development files 
>> > into
>> > /usr/lib/triplet too is at least harmless, and that Multi-Arch: same is
>> > appropriate for -dev packages where all the arch-dependent files are in
>> > arch-specific directories? I'd rather not break future work if -dev 
>> > packages
>> > aren't really settled yet.
>>
>> The policy exception is currently not written to permit this.  Please don't
>> upload packages to the archive that violate policy.
>
> I'd interpreted Policy §9.1.1 (3) as allowing anything that would normally be
> installed to [/usr]/lib to be installed to [/usr]/lib/TRIPLET, but looking
> at it again, it does indeed specify "object files, internal binaries, and
> libraries". Am I right in thinking that this means the following?

I'm just stating what is required for a package to conform to
Multi-Arch: same. In cases where you feel policy disagrees or support is
still unclear that means the package can not be Multi-Arch: same yet.

> * the real runtime library (libdbus-1.so.3.4.0) and the SONAME symlink
>   (libdbus-1.so.3) SHOULD move to the multiarch directory

MUST for Multi-Arch: same.

> * binaries appropriate for ${libexecdir} SHOULD move to a subdirectory of the
>   multiarch directory

MUST for Multi-Arch: same.

> * the development symlink (libdbus-1.so) and the static library (libdbus-1.a)
>   MAY move to the multiarch directory

MUST for Multi-Arch: same. BUT -dev packages need not be multiarchified
yet. Do test and upload to experimental and such when playing with this.

> * plugins (e.g. /usr/lib/gtk-2.0/modules) MAY move to a subdirectory of the
>   multiarch directory (but this will need coordination between the maintainers
>   of the plugin loader and the plugins)

MUST for Multi-Arch: same. And gtk-2.0 is one of the important libs that
people need multiarchified. Having a multiarch libgtk but no multiarch
plugins will make little sense.

> * .la files MUST NOT move to a subdirectory of the multiarch directory;
>   http://wiki.debian.org/ReleaseGoals/LAFileRemoval will eventually make this 
>   irrelevant
>   [rationale: earlier in the thread, Goswin explained that this doesn't work]

Or at least is untested. Given the release goal it seems pointless to
care. But as long as you have an .la file and that must be in /usr/lib
the -dev package can not be Multi-Arch: same, which is not a problem.

> * architecture-specific header files currently found in /usr/lib (on my
>   system: D-Bus, GLib, Gtk, ejabberd) MUST NOT move to a multiarch directory
>   [rationale: Policy doesn't yet say they can]

I disagree there.

| 9.1.1 File System Structure
|...
| Applications may also use a single subdirectory under
| /usr/lib/triplet. 

I believe that means anything that is allowed in /usr/lib/package/ is
also allowed in /usr/lib/triplet/package/.

MUST for Multi-Arch: same. BUT -dev need not be multiarchified yet.

> * miscellaneous architecture-specific non-library data (pkg-config .pc files)
>   MUST NOT move to a multiarch directory
>   [rationale: Policy doesn't yet say they can]

Again I disagree. I don't think policy is blocking here. The problem is
pkg-config supporting it. Fix for pkg-config pending? (see other mail in
this thread)

MUST for Multi-Arch: same. BUT -dev need not be multiarchified yet.

> In each case where I'm wrong, could you please explain whether putting those
> files in multiarch directories is currently forbidden, discouraged, encouraged
> or recommended?
>
> For autotools packages that hard-code paths, usually because they have plugins
> (gtk-2.0 is a good example), the only reliable way to divert the runtime
> library into /usr/lib seems to be to use `./configure --libdir=TRIPLET`,
> which means that files destined for any directory of the form ${libdir}/foo
> will get diverted too, even if current Policy forbids this. Should maintainers
> be using --libdir and then moving forbidden files (e.g. pkg-config files)
> back to the arch-neutral location, or encouraging upstreams to provide
> more --whateverdir switches, or what?
>
> A concrete example: if I understand correctly, Goswin suggests I use --libdir
> on dbus, to make it more exemplary, and in particular not misleading for
> maintainers of packages that do hard-code paths. However, I would then need
> to move the .pc file and the arch-specific header back out of the multiarch
> directory to comply with what you said, editing the .pc file to have the
> right path for the arch-specific header in the process, unless I patch
> configure.ac to add some sort of --archincludedir option, autoreconf, and
> use that option.

With the exception of .la and .pc files I do not think that moving the
files is harmfull nor that policy forbids it (see 9.1.1). And they need
to move there eventually anyway (or to /usr/include/triplet/). Further
the files move there

Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Henry-Nicolas Tourneur]

"Guus Sliepen"  Ecrivait:

>> So it's more some kind of errors from my side because that wasn't very
>> clear.
>> Should I update this bug to put MIT-like as license ?
> 
> It's better to include the whole license if it isn't exactly equal to a
> standard license.
> 

I'll update the package tonight (GMT+1 hour) as I'm currently at work - I
don't have all the needed things (and also fix lintian warning btw).

Should I do something particular about that license matter ? except
providing the COPYING file within the packages ?

TIA.
> -- 
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 
> 



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Marco d'Itri]

On Feb 03, Guus Sliepen  wrote:

> But, that's still a license. But look carefully, it says "without fee" in the
> license. I don't know if that means "you can use it without paying anyone" or
> "you can only redistribute it if you don't charge anyone".
The first meaning is the one widely accepted and used for other Debian
packages with similar terms.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: upload lost ???

[Norbert Preining]

Dear Luk, dear Jörg, dear ftp-master, dear whoever,

please help me with fixing that problem:

Now I have the following problem:
- sending a dcut rm of the files I get:
Log of processing your commands file
/dcut.Norbert_Preining__preining_debian_org_.1265157430.5010.commands:

> rm --searchdirs maildir-utils_0.6-1_amd64.changes
maildir-utils_0.6-1_amd64.changes did not match anything
No files to delete
> rm --searchdirs maildir-utils_0.6-1.dsc
maildir-utils_0.6-1.dsc did not match anything
No files to delete
> rm --searchdirs maildir-utils_0.6.orig.tar.gz
maildir-utils_0.6.orig.tar.gz did not match anything
No files to delete
> rm --searchdirs maildir-utils_0.6-1.diff.gz
maildir-utils_0.6-1.diff.gz did not match anything
No files to delete
> rm --searchdirs maildir-utils_0.6-1_amd64.deb
maildir-utils_0.6-1_amd64.deb did not match anything
No files to delete


Then uploading again I get:
/maildir-utils_0.6-1_amd64.changes is already present on target host:
maildir-utils_0.6-1_amd64.deb
Either you already uploaded it, or someone else came first.
Job maildir-utils_0.6-1_amd64.changes removed.


So *how* am I supposed to clean up that mess?

Thanks a lot.

Best wishes

Norbert

Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria   Debian TeX Task Force
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

TOOTING BEC (n.)
A car behind which one draws up at the traffic lights and hoots at
when the lights go green before realising that the car is parked and
there is no one inside.
--- Douglas Adams, The Meaning of Liff


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#568161: ITP: tacacs+ -- TACACS+ authentication daemon

[Matt Zagrabelny]

On Wed, 2010-02-03 at 11:01 +0100, Guus Sliepen wrote:
> On Wed, Feb 03, 2010 at 10:37:08AM +0100, Tollef Fog Heen wrote:
> 
> > ]] Tourneur Henry-Nicolas 
> > 
> > | * License : No license, only a copyright file
> > 
> > Surely that makes it illegal for us to distribute?
> 
> Actually, it does have a license, which is in the COPYING file and at the top
> of all the source code files:
> 
>Permission to use, copy, modify, and distribute this software for
>any purpose and without fee is hereby granted, provided that this
>copyright and permission notice appear on all copies of the
>software and supporting documentation, the name of Cisco Systems,
>Inc. not be used in advertising or publicity pertaining to
>distribution of the program without specific prior permission, and
>notice be given in supporting documentation that modification,
>copying and distribution is by permission of Cisco Systems, Inc.
> 
> I think this can be distributed in the non-free section?

The old version of this package was distributed in main.

$ apt-cache policy tac-plus
tac-plus:
  Installed: 1:4.0.4.alpha-14.2
  Candidate: 1:4.0.4.alpha-14.2
  Version table:
 *** 1:4.0.4.alpha-14.2 0
100 /var/lib/dpkg/status
 1:4.0.4.alpha-14 0
500 http://ftp.us.debian.org oldstable/main Packages


-- 
Matt Zagrabelny - mzagr...@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 4096R/42A00942 2009-12-16
Fingerprint: 5814 2CCE 2383 2991 83FF  C899 07E2 BFA8 42A0 0942

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot


signature.asc
Description: This is a digitally signed message part

Re: upload lost ???

[Luk Claes]

Norbert Preining wrote:
> Dear Luk, dear Jörg, dear ftp-master, dear whoever,
> 
> please help me with fixing that problem:
> 
> Now I have the following problem:
> - sending a dcut rm of the files I get:
> Log of processing your commands file
> /dcut.Norbert_Preining__preining_debian_org_.1265157430.5010.commands:
> 
>> rm --searchdirs maildir-utils_0.6-1_amd64.changes
> maildir-utils_0.6-1_amd64.changes did not match anything
> No files to delete
>> rm --searchdirs maildir-utils_0.6-1.dsc
> maildir-utils_0.6-1.dsc did not match anything
> No files to delete
>> rm --searchdirs maildir-utils_0.6.orig.tar.gz
> maildir-utils_0.6.orig.tar.gz did not match anything
> No files to delete
>> rm --searchdirs maildir-utils_0.6-1.diff.gz
> maildir-utils_0.6-1.diff.gz did not match anything
> No files to delete
>> rm --searchdirs maildir-utils_0.6-1_amd64.deb
> maildir-utils_0.6-1_amd64.deb did not match anything
> No files to delete
> 
> 
> Then uploading again I get:
> /maildir-utils_0.6-1_amd64.changes is already present on target host:
> maildir-utils_0.6-1_amd64.deb
> Either you already uploaded it, or someone else came first.
> Job maildir-utils_0.6-1_amd64.changes removed.

Apparently the package is in /src/ftp.debian.org/queue/unchecked (which
you can see on merkel).

> So *how* am I supposed to clean up that mess?

Either upload a higher version or have ftpmaster move that manualy I guess.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

git and quilt

[Matt Zagrabelny]

Greetings,

I read through the git-buildpackage docs and also a HOWTO by Russ
Allbery [1] regarding git and Debian packaging. I am wondering if those
who use git to manage their source package development are also using
the debian/patches mechanism for modifying the upstream tarball.

I receive the following error from lintian and am looking for some
guidance/best practices.

% lintian --pedantic cdpr_2.3-3.dsc
P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
1 more

I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
package.

Thanks for the tips,

[1] http://www.eyrie.org/~eagle/notes/debian/git.html

-- 
Matt Zagrabelny - mzagr...@d.umn.edu - (218) 726 8844
University of Minnesota Duluth
Information Technology Systems & Services
PGP key 4096R/42A00942 2009-12-16
Fingerprint: 5814 2CCE 2383 2991 83FF  C899 07E2 BFA8 42A0 0942

He is not a fool who gives up what he cannot keep to gain what he cannot
lose.
-Jim Elliot


signature.asc
Description: This is a digitally signed message part

Re: git and quilt

[Josselin Mouette]

Le mercredi 03 février 2010 à 16:25 -0600, Matt Zagrabelny a écrit : 
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

http://packages.debian.org/sid/topgit

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: git and quilt

[Russ Allbery]

Matt Zagrabelny  writes:

> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I generally do not.  Doing so with a tool like TopGit is a little awkward
and requires more steps, and I don't see much utility in doing so.  I
think it's easier to just manage Git branches.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: git and quilt

[James Vega]

On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I receive the following error from lintian and am looking for some
> guidance/best practices.
> 
> % lintian --pedantic cdpr_2.3-3.dsc
> P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and
> 1 more

This isn't an error.  It's an informational message only shown in
pedantic mode.  From lintian(1):

“Pedantic tags are Lintian at its most pickiest and include checks for
particular Debian packaging styles and checks that many people disagree
with.  Expect false positives and Lintian tags that you don't consider
useful if you use this option.”

In other words, if you think the tag is useful then fix it, otherwise
ignore it.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Re: git and quilt

[martin f krafft]

also sprach Russ Allbery  [2010.02.04.1208 +1300]:
> I generally do not.  Doing so with a tool like TopGit is a little awkward
> and requires more steps, and I don't see much utility in doing so.  I
> think it's easier to just manage Git branches.

All that TopGit really does is help you in merging depending
branches into dependent ones if the former have updated. You also
don't have to always update them, as TopGit works quite well even if
branches are out-of-date. tg-summary is still useful to keep an
overview.

But yes, there are still some open issues with TopGit that prevent
me from unconditionally adovating it.

  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=topgit;exclude=tags:fixed;exclude=tags:fixed-upstream;exclude=tags:pending;exclude=tags:wontfix;exclude=pending:done;dist=unstable

-- 
 .''`.   martin f. krafft   Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"sometimes the urge to do bad is nearly overpowering"
  -- ben horne


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: multiarch and pkg-config

[Peter Samuelson]

[Goswin von Brederlow]
> But how would -dev packages signal that they need support for this?
> They do not depend on pkg-config as they are usable without. Should
> they Breaks: pkg-config (<< ver)? Seems too strong.

Alternatively, create a symlink into /usr/lib/pkgconfig/ in postinst,
if one isn't already present.  Indeed, dh_makeshlibs could do this in
the same way it adds those 'ldconfig' calls.  (Well, I suppose some
shlib packages don't run dh_makeshlibs -s, instead using -p on each
library package ... but they could if they wanted.)
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org