On mer., 2011-08-31 at 11:59 +0100, Wolodja Wentland wrote:
>
> Could you elaborate on your reasons and your intentions for making the
> distinction?
Policy 7.2, mostly, and the fact depends are installed (obviously),
recommends are installed by default (but that can be disabled and one
can remov
> Wolodja Wentland writes:
> is there a specific reason why metapackages depend rather then
> recommend packages they are meant to pull in?
> The rationale behind this question is [0] that we see a plethora of
> users in #debian who ask questions like: "Why did apt remove all my
> syste
* Josselin Mouette [2011-09-01 09:52 +0200]:
> I think we could solve a lot of those problems by treating metapackages
> specially in APT.
Ubuntu has a section "metapackages", introducing such a section in
Debian could be the first step to treat metapackages specially.
Carsten
--
To UNSUBSCRI
Le lundi 29 août 2011 à 16:40 +0100, Wolodja Wentland a écrit :
> is there a specific reason why metapackages depend rather then recommend
> packages they are meant to pull in?
There are several reasons for that - at least for the GNOME ones.
The first one is to guarantee that newly added packag
On Tue, Aug 30, 2011 at 17:37 +0200, Yves-Alexis Perez wrote:
> On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote:
> >
> > I agree that a general change of all metapackages is probably not a good
> > idea,
> > but I think that changing the root-nodes of the metapackage tree (i.e.
> > met
but if you mean strict "meta" as in it has no files but depends on real
specific libraried packages ...
as far as I know strict "meta" are already well versioned and any package, such as perl, acts as a
"meta" in some way by depending on other versions of packages to "fully install" - in the s
On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote:
>
> I agree that a general change of all metapackages is probably not a good idea,
> but I think that changing the root-nodes of the metapackage tree (i.e.
> metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is in
>
Let me say this (i'm working on a new tsort you can say - but slowly as it's
not my day job).
if "Virtual package" is the same as "meta package"... (which ends up being a simple lookup before
package list ordering / dropping)
Why worry about Recommends or Suggests ? Only after dpkg develops
On Tue, Aug 30, 2011 at 12:32 +0200, Cyril Brulebois wrote:
> Wolodja Wentland (30/08/2011):
> > It is my impression that the problems mentioned in my initial mail can
> > be solved by changing metapackages (like those mentioned by Cyril in
> > his reply) to use Recommends instead of Depends.
> >
On 30/08/2011 16:46, Andreas Tille wrote:
> On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote:
>> It is my impression that the problems mentioned in my initial mail can be
>> solved by changing metapackages (like those mentioned by Cyril in his
>> reply) to use Recommends instead of
On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote:
> > > is there a specific reason why metapackages depend rather then recommend
> > > packages they are meant to pull in?
>
> I never meant to imply that *all* metapackages use Depends.
For my perception of your sentence at least a
Wolodja Wentland (30/08/2011):
> It is my impression that the problems mentioned in my initial mail can
> be solved by changing metapackages (like those mentioned by Cyril in
> his reply) to use Recommends instead of Depends.
>
> I am, however, not entirely sure if there are any good reasons for
On Tue, Aug 30, 2011 at 09:26 +0200, Andreas Tille wrote:
> On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> > is there a specific reason why metapackages depend rather then recommend
> > packages they are meant to pull in?
> The statement that metapackages depend from packages
Andreas Tille (30/08/2011):
> On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> > is there a specific reason why metapackages depend rather then
> > recommend packages they are meant to pull in?
>
> The statement that metapackages depend from packages is not true in
> general.
On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> is there a specific reason why metapackages depend rather then recommend
> packages they are meant to pull in?
The statement that metapackages depend from packages is not true in
general. A counter example are those metapackages
On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> they decided to remove one of (typically) gnome's dependencies, which
> caused the metapackage to be removed as well.
That also causes an effect of "GNOME gets removed!" even without any
additional autoremoved packages :(
--
WBR
Ben Pfaff wrote:
In bug #262021, Norman Ramsey reported that the "autoreconf"
script provided by the autoconf package runs automake. Since
at the time autoconf merely recommended automaken, instead of
depending on it, this could fail.
To fix the bug, I changed the recommendation to a dependency
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I am torn between the two possibilities. On one hand, Debian policy is
> clear that packages should have full dependencies on all the programs
> that they may invoke. On the other hand, Ralf has a reasonable argument
> that it is the package being autoreco
On Wed, Jan 23, 2008 at 09:08:47 -0800, Ben Pfaff wrote:
> I am torn between the two possibilities. On one hand, Debian
> policy is clear that packages should have full dependencies on
> all the programs that they may invoke.
I disagree with that. Quoting policy 7.2:
The `Depends' fiel
On Mon, Sep 10, 2007 at 05:00:04AM +0300, Guillem Jover wrote:
> On Fri, 2007-08-31 at 00:15:10 -0700, Steve Langasek wrote:
> > On Fri, Aug 31, 2007 at 06:09:42AM +0300, Guillem Jover wrote:
> > > For libraries with versioned symbols, just checking for the needed
> > > version nodes should be enou
On Fri, 2007-08-31 at 00:15:10 -0700, Steve Langasek wrote:
> On Fri, Aug 31, 2007 at 06:09:42AM +0300, Guillem Jover wrote:
> > For libraries with versioned symbols, just checking for the needed
> > version nodes should be enough, and I'd say that adding symbols to
> > a previously existing versio
On Fri, Aug 31, 2007 at 06:09:42AM +0300, Guillem Jover wrote:
> On Wed, 2007-08-22 at 15:19:02 +0200, Raphael Hertzog wrote:
> > I think my work is mostly ready for unstable as it is. The last step is to
> > convince Guillem Jover, the main dpkg maintainer, to merge that in the
> > master branch.
Hi,
On Fri, 31 Aug 2007, Guillem Jover wrote:
> On Wed, 2007-08-22 at 15:19:02 +0200, Raphael Hertzog wrote:
> > I think my work is mostly ready for unstable as it is. The last step is to
> > convince Guillem Jover, the main dpkg maintainer, to merge that in the
> > master branch. He believes that
Hi Raphael,
On Wed, 2007-08-22 at 15:19:02 +0200, Raphael Hertzog wrote:
> I think my work is mostly ready for unstable as it is. The last step is to
> convince Guillem Jover, the main dpkg maintainer, to merge that in the
> master branch. He believes that supporting odd cases encourages bad
> pra
Hi,
On Wed, 2007-08-22 at 15:08:16 +0100, Neil Williams wrote:
> Raphael - I'm in the middle of a rewrite of dpkg-cross, including the
> diversion of dpkg-shlibdeps:
> So far, pre1 is largely complete for dpkg-cross and the
> dpkg-buildpackage diversion, barring an unknown number of possible
> co
On Wed, 2007-08-22 at 20:38 +0100, Thiemo Seufer wrote:
> > Can anyone explain me why there's randomness in symbol mangling? If I
> > compare
> > the symbols file of gnunet-qt for example I get differences like this
> > between
> > i386 and alpha:
> > @@ -67,10 +67,10 @@
> > [EMAIL PROTECTED]
On Wed, Aug 22, 2007 at 03:19:02PM +0200, Raphael Hertzog wrote:
> 5/ Fifth example, it looks like 64 bits ports tend to have differences in
> common
> like on libneon2.6 where various functions suffixed by "64" disappear on those
> arches (ne_get_range64, ne_set_request_body_fd64,
> ne_set_requ
Raphael Hertzog wrote:
[snip]
> 2/ Second example, libconfig0 has a supplementary symbols
> _PROCEDURE_LINKAGE_TABLE_ on sparc and alpha. I don't know where it comes
> from.
> Is this a internal symbols that I missed?
> On powerpc it has _SDA_BASE_ and _SDA2_BASE_. Same question as above.
> On amd
On Wed, Aug 22, 2007 at 03:19:02PM +0200, Raphael Hertzog wrote:
> Hi,
>
> 2/ Second example, libconfig0 has a supplementary symbols
[...]
> _PROCEDURE_LINKAGE_TABLE_ on sparc and alpha. I don't know where it comes
> from.
> Is this a internal symbols that I missed?
http://www.cygwin.com/ml/binu
On Wed, 22 Aug 2007, Neil Williams wrote:
> I'd appreciate any input you can provide because dpkg-shlibdeps isn't
> particularly familiar to me and I purposely left this part of
> dpkg-cross until this stage of the rewrite.
>
> I'd like to be able to not need dpkg-shlibdeps in dpkg-cross but if t
On Wed, 22 Aug 2007 15:19:02 +0200
Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> Everything is available in the git branch:
> http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog;h=dpkg-shlibdeps-buxy
>
> I think my work is mostly ready for unstable as it is. The last step is to
> convince Guillem Jo
On Mon, Jun 18, 2007 at 12:01:23PM +0200, Loïc Minier wrote:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...
> I think this is fine; the resulting "symb
Le lundi 18 juin 2007 à 10:08 +0100, Raphael Hertzog a écrit :
> The file in debian is *not* updated, that's precisely the point of this
> discussion. Joss wants the maintainer to update it beforehand, I let the
> maintainer update it after its final build but it will then be used only
> for the ne
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
>> > The file in debian is *not* updated, that's precisely the point of this
>> > discussion. Joss wants the maintainer to update it beforehand, I let the
>> > maintainer update it after its final build
* Loïc Minier ([EMAIL PROTECTED]) [070618 12:04]:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...
>
> I think this is fine; the resulting "symbols" file
* Raphael Hertzog ([EMAIL PROTECTED]) [070618 11:36]:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild once knowing that it will fail... l
On Mon, 18 Jun 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...
I have full control on the kind of changes that I allow in the
generated symbols file compared to the provided f
On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
> > The file in debian is *not* updated, that's precisely the point of this
> > discussion. Joss wants the maintainer to update it beforehand, I let the
> > maintainer update it after its final build but it will then be used only
> > for the next upl
On Mon, Jun 18, 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...
I think this is fine; the resulting "symbols" file can make strict
assumptions.
You don't expect dh_makeshl
On Mon, Jun 18, 2007 at 10:08:36AM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild onc
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
>> > The generated file is updated... and the file in the source package
>> > doesn't need to be updated so often. Additionnaly you can avoid having to
>> > rebuild once knowing that it will fail... let the build
On Mon, 18 Jun 2007, Mike Hommey wrote:
> > The generated file is updated... and the file in the source package
> > doesn't need to be updated so often. Additionnaly you can avoid having to
> > rebuild once knowing that it will fail... let the build update the
> > generated file, get the diff from
On Mon, Jun 18, 2007 at 09:50:48AM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> On Mon, 18 Jun 2007, Josselin Mouette wrote:
> > Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > > - we have different levels of check that can make dpkg-gensymbols fail
> > > (w
Hi,
On Mon, 18 Jun 2007, Josselin Mouette wrote:
> Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > - we have different levels of check that can make dpkg-gensymbols fail
> > (with option -c). By default level 1 is activated, it will fail
> > if some symbols disappeared. L
Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> - we have different levels of check that can make dpkg-gensymbols fail
> (with option -c). By default level 1 is activated, it will fail
> if some symbols disappeared. Level 2 will also fail if new symbols are
> introduced wi
* Raphael Hertzog ([EMAIL PROTECTED]) [070617 18:15]:
> if some symbols disappeared. Level 2 will also fail if new symbols are
> introduced with prior update of the debian/symbols file. Level 3 and 4
^ without
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUB
On Tue, 12 Jun 2007, Raphael Hertzog wrote:
> On Thu, 07 Jun 2007, Raphael Hertzog wrote:
> > Otherwise, the discussions in this thread lead to several interesting
> > points (listed in the TODO in the repository) which will require some
> > rewrite and optimization of the format of the symbols fil
On Thu, 07 Jun 2007, Raphael Hertzog wrote:
> Otherwise, the discussions in this thread lead to several interesting
> points (listed in the TODO in the repository) which will require some
> rewrite and optimization of the format of the symbols file. I'll update
> the wiki page and my implementation
On Thu, 07 Jun 2007, Steve Langasek wrote:
> Or are you questioning that most libraries ought to be using version
> scripts? I said they ought to, not that they currently did; and using
Yeah, that. Apparently my english failed me, and I didn't parse what you
meant correctly.
I am all for symbol
Le jeudi 07 juin 2007 à 20:44 +0200, Pierre Habouzit a écrit :
> symbol visibility support in gcc is not that old, and many upstream
> don't use it (yet).
libtool has supported -export-symbols since 1998 and
-export-symbols-regex since 1999.
> For them there is many many many private symbols in
On Thu, 07 Jun 2007, Russ Allbery wrote:
> There's an argument to be made that shlibs files should be provided by the
> -dev packages, not the library packages. We should at least think about
> whether the symbols files belong in the -dev package. They're used to
> generate dependencies for packa
* Julien Cristau ([EMAIL PROTECTED]) [070607 18:04]:
> On Thu, Jun 7, 2007 at 17:56:46 +0200, Andreas Barth wrote:
>
> > * Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> > > On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL
> > > PROTECTED]> wrote:
> > > > symbols MUST NEVER dis
Mike Hommey <[EMAIL PROTECTED]> writes:
> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
>> Otherwise, the discussions in this thread lead to several interesting
>> points (listed in the TODO in the repository) which will require some
>> rewrite and optimization of the format of the symbols file. I'll
On Thu, Jun 07, 2007 at 10:28:35PM +0200, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Otherwise, the discussions in this thread lead to several interesting
> points (listed in the TODO in the repository) which will require some
> rewrite and optimization of the format of the symbols file. I'll up
On Thu, Jun 07, 2007 at 11:23:18PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 07 Jun 2007, Steve Langasek wrote:
> > It's been possible to avoid the export of symbols for years using version
> > scripts, which most libraries also ought to be using anyway.
> Maybe on Solaris. On Linux? Who
On Thu, Jun 07, 2007 at 06:03:49PM +0200, Julien Cristau wrote:
> On Thu, Jun 7, 2007 at 17:56:46 +0200, Andreas Barth wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> > > On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL
> > > PROTECTED]> wrote:
> > > > symbols MUST
On Thu, 07 Jun 2007, Steve Langasek wrote:
> It's been possible to avoid the export of symbols for years using version
> scripts, which most libraries also ought to be using anyway.
Maybe on Solaris. On Linux? Who are you kidding?
--
"One disk to rule them all, One disk to find them. One disk
On Thu, Jun 07, 2007 at 08:44:32PM +0200, Pierre Habouzit wrote:
> On Thu, Jun 07, 2007 at 07:15:22PM +0200, Bernhard R. Link wrote:
> > * Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
> > > > Reality is that this build must fail with a proper warning, so that the
> > > > maintainer can decide
Hello,
On Mon, 04 Jun 2007, Raphael Hertzog wrote:
> What comes next
> ---
> Up to now, I only tested those scripts on a few packages. What comes next
> is some archive-wide work:
> - I want to generate ready-to-use symbols file for all libraries
> initialized with packages from etch
On Thu, Jun 07, 2007 at 07:15:22PM +0200, Bernhard R. Link wrote:
> * Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
> > > Reality is that this build must fail with a proper warning, so that the
> > > maintainer can decide if this is an excption and ok or whether he should
> > > cluebat upstrea
On Thu, 7 Jun 2007 19:15:22 +0200, Bernhard R Link <[EMAIL PROTECTED]> said:
> * Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
>> > Reality is that this build must fail with a proper warning, so that
>> > the maintainer can decide if this is an excption and ok or whether
>> > he should clueb
Raphael Hertzog wrote:
> I double-checked this and no, it's not the case. Extract from dpkg-shlibdeps:
> while () {
> s/\s*\n$//; next if m/^\#/;
> if (!m/^\s*(?:(\S+):\s+)?(\S+)\s+(\S+)/) {
> &warn(sprintf(_g("shared libs info file \`%s' line %d: bad line
> \`%s'")
* Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
> > Reality is that this build must fail with a proper warning, so that the
> > maintainer can decide if this is an excption and ok or whether he should
> > cluebat upstream about a what soname means.
> >
> Reality is that libs export private sym
Raphael Hertzog wrote:
> For me the only significant advantage of this proposed format is that it
> offers the possibility to add additional automatic dependencies at the
> package level and not only at the symbol level.
>
> Joey, how would you integrate this new scheme if I decided to reuse the
>
On Thu, Jun 7, 2007 at 17:56:46 +0200, Andreas Barth wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> > On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL PROTECTED]>
> > wrote:
> > > symbols MUST NEVER disappear!
> >
> > Reality is that it happens.
>
> Reality is that
* Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL PROTECTED]>
> wrote:
> > > The real lib has precedence over the provided symbols file.
> > > - any new symbol is added and marked with mininal version being the
> > > current
> > >
On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL PROTECTED]>
wrote:
> > The real lib has precedence over the provided symbols file.
> > - any new symbol is added and marked with mininal version being the current
> > version of the package
> > - a symbol that disappeared is marked
* Raphael Hertzog ([EMAIL PROTECTED]) [070606 14:03]:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > On Wed, Jun 06, 2007 at 09:15:02AM +0200, Raphael Hertzog wrote:
> > > Now, if we have people store symbols in shlibs file, it means that
> > > dh_installdeb would install the shlibs file with sym
On Thu, Jun 07, 2007 at 09:05:23AM +0200, Raphael Hertzog wrote:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > Can you expand? I don't see at all how libgl would "benefit" from this new
> > > approach. The current shlibs is already very lax and non-versioned.
> > Yes, and that's the problem:
Le jeudi 07 juin 2007 à 09:05 +0200, Raphael Hertzog a écrit :
> > Yes, and that's the problem: I know the libgl shlibs to have been wrong in
> > certain corner cases involving uncommon symbols (whether those are
> > implementors adding their own extensions, or failing to implement the
> > standar
On Wed, 06 Jun 2007, Steve Langasek wrote:
> > Can you expand? I don't see at all how libgl would "benefit" from this new
> > approach. The current shlibs is already very lax and non-versioned.
>
> Yes, and that's the problem: I know the libgl shlibs to have been wrong in
> certain corner cases i
On Wed, Jun 06, 2007 at 02:33:58PM +0200, Raphael Hertzog wrote:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > > Consider cases where you want to declare that more than one package
> > > > satisfies the dependency -- we do have libraries using that today in
> > > > their
> > > > shlibs. I do
On Wed, Jun 06, 2007 at 09:53:41PM +0200, Kurt Roeckx wrote:
> On Wed, Jun 06, 2007 at 07:55:28PM +0200, Julien Cristau wrote:
> > On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
> > > Just as better alternative IMHO, please consider using `eu-readelf -ds`
> > > from elfutils.
> > elfu
* From: Julien Cristau
> Newsgroups: gmane.linux.debian.devel.general
>
> On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
>
>> Just as better alternative IMHO, please consider using `eu-readelf -ds`
>> from elfutils.
>
> elfutils isn't build-essential. binutils is, and does the job, so "
On Wed, Jun 06, 2007 at 07:55:28PM +0200, Julien Cristau wrote:
> On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
>
> > Just as better alternative IMHO, please consider using `eu-readelf -ds`
> > from elfutils.
>
> elfutils isn't build-essential. binutils is, and does the job, so "it's
On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
> Just as better alternative IMHO, please consider using `eu-readelf -ds`
> from elfutils.
elfutils isn't build-essential. binutils is, and does the job, so "it's
better IMHO" isn't a particularly compelling reason to make all packages
bu
* From: Steve Langasek
* Date: Wed, 6 Jun 2007 03:34:59 -0700
[]
> FWIW, in the prototyping I did in the unixodbc package I made the symbol
> version and the symbol name two separate fields separated by whitespace,
> because this made it easier to generate files of this format with objdump -T
> and
On Wed, 06 Jun 2007, Loïc Minier wrote:
> On Wed, Jun 06, 2007, Raphael Hertzog wrote:
> > We could then have the package field contain multiple packages (separated
> > by "," or "|" or whatever) and have dpkg-shlibdeps generate pkg1 (>=
> > min-ver) | pkg2 (>= min-ver).
>
> I don't think so; at
On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > Consider cases where you want to declare that more than one package
> > > satisfies the dependency -- we do have libraries using that today in their
> > > shlibs. I do think it's necessary here to support the full range of
> > > dependency semantics
On Wed, 06 Jun 2007, Steve Langasek wrote:
> On Wed, Jun 06, 2007 at 09:15:02AM +0200, Raphael Hertzog wrote:
> > Now, if we have people store symbols in shlibs file, it means that
> > dh_installdeb would install the shlibs file with symbols. That could be
> > almost enough except that we really wa
On Wed, Jun 06, 2007 at 01:42:55PM +0200, Raphael Hertzog wrote:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > It would be much more worth to drop the package name from the
> > > dependencies. Except a few corner cases (which could probably be
> > > worked around some other way), they are alwa
On Wed, Jun 06, 2007, Raphael Hertzog wrote:
> We could then have the package field contain multiple packages (separated
> by "," or "|" or whatever) and have dpkg-shlibdeps generate pkg1 (>=
> min-ver) | pkg2 (>= min-ver).
I don't think so; at least sometimes you want to depend on
non-versionne
On Wed, 06 Jun 2007, Steve Langasek wrote:
> > It would be much more worth to drop the package name from the
> > dependencies. Except a few corner cases (which could probably be
> > worked around some other way), they are always the package name
> > inside which the library is...
>
> > The >= is a
On Wed, Jun 06, 2007 at 09:53:22AM +0200, Raphael Hertzog wrote:
> What you propose would look like:
> libc 6
> [EMAIL PROTECTED] libc6 2.3.6.ds1-13
> [EMAIL PROTECTED] libc6 2.3.6.ds1-13
> Because of the "^\s*" you can't use starting spaces as a differentiating
> factor. The lines wit
On Wed, Jun 06, 2007 at 09:15:02AM +0200, Raphael Hertzog wrote:
> Now, if we have people store symbols in shlibs file, it means that
> dh_installdeb would install the shlibs file with symbols. That could be
> almost enough except that we really want a check that the information
> stored in those f
On Tue, Jun 05, 2007 at 08:14:18PM +0200, Mike Hommey wrote:
> On Tue, Jun 05, 2007 at 02:02:59PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote:
> > [1] #363133
> > [2] Would it be worthwhile to support multiple symbols on one line to
> > save even more space?
> > symbol [symbol...] de
On Tue, Jun 05, 2007 at 02:02:59PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote:
> [1] #363133
> [2] Would it be worthwhile to support multiple symbols on one line to
> save even more space?
> symbol [symbol...] dependencies...
It would be much more worth to drop the package name from the
On Tue, 05 Jun 2007, Joey Hess wrote:
> It seems that this could be extended to include symbol information:
>
> [package-type:] library-name soname-version-number dependencies...
> [symbol dependencies...]
> [...]
>
> Like the package-type extension, this extra information will be
> t
On Tue, 05 Jun 2007, Joey Hess wrote:
> Note that policy doesn't fully document[1] the current shlibs format,
> which is:
>
> [package-type:] library-name soname-version-number dependencies...
>
> It seems that this could be extended to include symbol information:
>
> [package-type:] library-nam
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Russ Allbery]
>> They *usually* do, but not all E tags are certain problems. Of course,
>> maintainers could use overrides.
> I'm opposed to adding overrides to my packages for cases where, in my
> view, lintian should somehow have enough informatio
[Russ Allbery]
> They *usually* do, but not all E tags are certain problems. Of course,
> maintainers could use overrides.
I'm opposed to adding overrides to my packages for cases where, in my
view, lintian should somehow have enough information to see the case as
a false positive. I use them o
Felipe Sateler <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> The primary barrier to enforcing the use of lintian is #243976. lintian
>> needs to get much better about identifying the source of checks, the
>> certainty that something is wrong, and the severity level so that dak
>> can run li
Steve Langasek wrote:
> On Tue, Jun 05, 2007 at 04:47:07PM -0400, Felipe Sateler wrote:
>
>> > Throwing a sensible error at build-time if the soname has changed
>> > without a package name change is also something that needs to be done,
>> > as well as throwing an error at build-time if symbols l
Russ Allbery wrote:
> Felipe Sateler <[EMAIL PROTECTED]> writes:
>
>> What you want may be achieved by enforcing the use of lintian, but I
>> don't know how that can be done.
>
> The primary barrier to enforcing the use of lintian is #243976. lintian
> needs to get much better about identifying
On Tue, Jun 05, 2007 at 04:47:07PM -0400, Felipe Sateler wrote:
> > Throwing a sensible error at build-time if the soname has changed without
> > a package name change is also something that needs to be done, as well as
> > throwing an error at build-time if symbols listed in the symbols file have
Felipe Sateler <[EMAIL PROTECTED]> writes:
> What you want may be achieved by enforcing the use of lintian, but I
> don't know how that can be done.
The primary barrier to enforcing the use of lintian is #243976. lintian
needs to get much better about identifying the source of checks, the
certai
Steve Langasek wrote:
> Throwing a sensible error at build-time if the soname has changed without
> a package name change is also something that needs to be done, as well as
> throwing an error at build-time if symbols listed in the symbols file have
> gone missing;
Lintian already does the firs
Steve Langasek wrote:
> > Finally, why not add the symbol informations to the shlibs file (that
> > can be done in a backwards compatible way) instead of creating yet
> > another control file ?
>
> I'd rather we didn't, even if it doesn't break anything it still abuses the
> shlibs file format as
[Josselin Mouette]
> A possible part of the solution would be a script parsing the diff
> between headers and emitting warnings such as:
> * type foo has changed, please check it doesn't affect functions
> bar/baz/...
> * enum foo has new possible values, please check it doesn'
* From: Steve Langasek
* Date: Tue, 5 Jun 2007 02:56:14 -0700
>
> On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
>> On Mon, 04 Jun 2007, Steve Langasek wrote:
[]
>> > Considering the number of bugs I see because of maintainers who don't
>> > notice
>> > they need to change packag
1 - 100 of 209 matches
Mail list logo
