Re: Fixing the Gobject Introspection mess

[Marco d'Itri]

On Sep 25, Julien Cristau  wrote:

> Doesn't this break co-installability of libfoo2.0-X and libfoo2.0-Y, if
> both install Foo-2.0.gir?
And what about multiarch?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Auto Backporting (Was: Backports of scientific packages)

[Andreas Tille]

On Sat, Sep 26, 2009 at 09:24:46AM +0100, Stephen Gran wrote:
> Sounds like you think it's a good idea.  Why not do it and let us know
> how you get on?

One point for you beeing the first raising this killer argument. ;-)

Andreas.

-- 
http://fam-tille.de
Klarmachen zum Ändern!


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

Re: Auto Backporting (Was: Backports of scientific packages)

[Stephen Gran]

This one time, at band camp, Andreas Tille said:
> So in short: we should choose the "well-defined" subset of packages
> which are candidates for autobackporting according to their feature to
> be buildable inside stable and using an control field to mark the
> packages that way. 

Sounds like you think it's a good idea.  Why not do it and let us know
how you get on?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Fixing the Gobject Introspection mess

[Josselin Mouette]

Le samedi 26 septembre 2009 à 07:56 +0200, Sebastian Dröge a écrit : 
> Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette:
> > 1. Package layout
> > 
> > GObject-introspection packages provide introspection data
> > in /usr/share/gir-1.0/Foo-X.Y.gir, and the
> > optional /usr/lib/girepository-1.0/Foo-X.Y.typelib.
> >
> > The packages should be architecture-dependent.
> 
> Only the typelib file actually is meant to be architecture-dependent
> (right, the GIR file could be arch-dep too if the headers and API parts
> of the sources (GObject properties/signals) are different from arch to
> arch. But who does that?!).

This has already happened, and this will happen again. For the same
reason we make headers architecture-dependent, I think we should make
GIR files the same.

> Also the GIR file is only meant for build time things so it could simply
> be placed in the -dev packages (as I've done so far).

There is no “build time” for interpreters. What do you mean exactly?

> Putting the typelib files in the shared library packages will create
> conflicts for soname changes. Not good (I know I placed them there in
> some packages). Creating a new package just for the typelib file is not
> good either ;)

Agreed. We should probably mandate to always split the introspection
files in a separate package.

Cheers, 
-- 
 .''`.  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

GObject introspection mini-policy, take 2

[Josselin Mouette]

After an insightful discussion with Sebastian, and taking into account
other suggestions from the list, here is a new proposal.



1. Directory layout

GObject-introspection data is generally provided in two formats: 
  * XML format in /usr/share/gir-1.0/Foo-X.Y.gir 
  * binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib


2. Binary introspection packages

The binary typelib file must be put in an architecture-dependent package
named after its namespace. The name should be gir1.0-NAMESPACE-VERSION.
For example, the package containing WebKit-1.0.typelib will be named
gir1.0-webkit-1.0.

Giant repositories of unrelated introspection data should be avoided.
(Under this rationale, gobject-introspection-repository will be split.)
However, related libraries that are known to evolve together can live in
the same package (example: Gst*-0.10).

Introspection packages belong in section libs for the moment. If there
are enough packages to justify it, a new section will be requested to
the FTP masters.


3. XML introspection data

The XML format introspection must be shipped in another
architecture-dependent* package of the same source.

  * This is so that it is guaranteed to be accessible at
build time by the tool that will compute the
dependencies for the .typelib files. 

If the source package also contains the library itself, this data should
be in the development binary package. If the introspection data is split
from the library source (e.g. for gobject-instrospection-repository), a
separate package containing this XML data can be created, in section
libdevel.

The package containing the XML data doesn’t need to depend on the
introspection package. It can contain XML data for several unrelated
libraries, since in the end it doesn’t depend on them.


4. Dependencies of introspection packages

Introspection packages must depend on the libraries they reference, with
a sufficient version for the symbols they reference.

For that effect, I propose to introduce a new helper, dh_girepository,
in the gobject-introspection package (which is already a
build-dependency for introspection packages). It would wrap
dpkg-shlibdeps so that the dependencies are the same as those of similar
ELF binaries.

Introspection packages must depend on other introspection packages that
are referenced through  statements. The helper should generate
such dependencies as well.

Packages containing the XML data don’t need any specific new
dependencies.


5. Dependencies on introspection packages

Currently, there are only Seed (JavaScript) scripts to use these
introspection packages. In the future, there might also be Python or
other interpreted languages.

Generating dependencies automatically for interpreted languages is not
reliable. Therefore, these packages must depend by hand on the
appropriate gir1.0-* packages. The interpreters themselves don’t need to
depend on packages they don’t use directly.


6. Example

Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
source generates the following files, put in the following packages:
libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib

libfoo-2.0-dev Depends: libfoo-2.0-3, libbar-3.0-dev
gir1.0-foo-2.0 Depends: ${gir:Depends} which expands to:
libfoo-2.0-3, gir1.0-bar-3.0

If foobar is a package containing the following JS script:
#! /usr/bin/seed
Foo = imports.gi.Foo;
// Stuff that uses the Foo 2.0 API

Then foobar Depends: gir1.0-foo-2.0



I’ve started preliminary work on dh_girepository. The first version will
be a bit hackish and will rely on building an intermediate binary
referencing the appropriate symbols that will be fed to dpkg-shlibdeps.
Doing better will require extending dpkg-shlibdeps so that it accepts
another input format than ELF (it doesn’t have to be the GObject XML
format, it could be anything easy to generate).

-- 
 .''`.  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

Bug#548450: ITP: librrdtool-oo-perl -- Object-oriented perl interface to RRDTool

[fabien]

Package: wnpp
Severity: wishlist
Owner: fabien 


* Package name: librrdtool-oo-perl
  Version : 0.25
  Upstream Author : Mike Schilli 
* URL : http://search.cpan.org/~mschilli/RRDTool-OO-0.25/
* License : (PERL)
  Programming Lang: (Perl)
  Description : Object-oriented perl interface to RRDTool

"RRDTool::OO" is an object-oriented interface to Tobi Oetiker's round
robin database tool *rrdtool*. It uses *rrdtool*'s "RRDs" module to get
access to *rrdtool*'s shared library.

"RRDTool::OO" tries to marry *rrdtool*'s database engine with the
dwimminess and whipuptitude Perl programmers take for granted. Using
"RRDTool::OO" abstracts away implementation details of the RRD engine,
uses easy to memorize named parameters and sets meaningful defaults for
parameters not needed in simple cases. For the experienced user,
however, it provides full access to *rrdtool*'s API (if you find a
feature that's not implemented, let me know).



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

Re: Auto Backporting (Was: Backports of scientific packages)

[Russell Coker]

On Sat, 26 Sep 2009, Rene Engelhard  wrote:
> > Shouldn't checking if Build-Depends are satisfiable in stable be enough?
> > And if it doesn't build that way, I'd say there's a bug in the package
> > anyways, because it should bump some build dependencies.
>
> build-deps are not necessarily runtime deps. Especially if
> stuff changed in the fs or for policy reasons and that is not reflected in
> the build-deps because the change is not in the build-deps.

The runtime dependencies should either be based on the versions of the 
packages that were compiled against (in which case they should be correct 
automaticall) or they will be based on some specific features (EG a new 
version of a package containing /bin/foo adds a new command-line option 
to /bin/foo) in which case an explicit versioned dependency should be 
sufficient (failure to do so would be a bug in any case).  It should not be 
THAT difficult to make a back-port build daemon refrain from building 
packages if the runtime dependencies can never be satisfied.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: Taiwan Mini-DebConf to visit world's tallest building, Google 2009.09.28

[pingooo]

Hi,

Please give me a contact phone number in case I need to find you on Monday.

Please send me the confirmed list of names by Sunday evening, too.

Thanks,
Ping

2009/9/18  :
> We have added a day trip to the Taiwan Mini-DebConf program, to visit
> the Google Corporation, in Taipei 101, the world's tallest building.
> http://wiki.debian.org/DebianTaiwan/MiniDebConf2009#Monday2009-09-28
>


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

DEP-3 update: Patch Tagging Guidelines

[Raphael Hertzog]

Hello,

following the recent comments on DEP-3 concerning its usage with git
format-patch I modified it (the patch is below). The resulting version
is on http://dep.debian.net/deps/dep3/. Feel free to comment if you see
further improvements.

--- a/web/deps/dep3.mdwn
+++ b/web/deps/dep3.mdwn
@@ -3,7 +3,7 @@
 Title: Patch Tagging Guidelines
 DEP: 3
 State: CANDIDATE
-Date: 2009-09-07
+Date: 2009-09-25
 Drivers: Raphael Hertzog 
 URL: http://dep.debian.net/deps/dep3
 Abstract:
@@ -47,11 +47,11 @@ information.
 
 Structure
 -
-The meta-information would be stored in a set of RFC-2822-like
+The meta-information would be stored in one or two set(s) of RFC-2822-like
 fields (the difference with RFC-2822 is that newlines are meaningful in
 the Description field, they are not simple continuation characters).
-Those fields should start on the first non-empty line (after having
-stripped whitespace characters at the start and end of
+The first set of fields (headers) should start on the first non-empty line
+(after having stripped whitespace characters at the start and end of
 lines).
 
 For patch-systems like dpatch that require the patch to be a standalone
@@ -62,9 +62,12 @@ multi-line fields, the subsequent lines should start with
 they start with a space once "`#` " (hash followed by a space) has been
 stripped from the beginning.
 
-The set of fields ends on the first empty line. Free-form comments can
-follow and be used for any other information that does not fit in the
-structured content.
+Sets of fields always end on the first empty line. Free-form comments can
+follow and should be considered as supplementary lines of the long
+description (see detailed explanations of the field). A second-set of fields
+(pseudo-headers) can start on any new paragraph. A line containing 3 dashes
+(---) should stop the parsing: lines after it are not relevant part of the
+meta-information.
 
 Any parser that expect those fields in patch headers should also
 accept non-structured content and simply consider the whole content
@@ -78,10 +81,14 @@ of any other distribution that tracks the same 
problem/patch. Vendor
 names are case-insensitive ("Fedora" and "fedora" refer to the same
 vendor).
 
-  * `Description` (required)
+  * `Description` or `Subject` (required)
 
 This obligatory field contains at least a short description on the
-first line. Supplementary lines can be used to provide a longer
+first line. When `Subject` is used, it is expected that the long
+description is outside of the structured fields. With `Description` it
+is possible to embed them in the field using continuation lines.
+
+In both cases, the long description allows for a more verbose
 explanation of the patch and its history.
 
 This field should explain why the patch is vendor-specicific (ex:
@@ -143,7 +150,7 @@ vendor).
 be "not-needed" to indicate that the patch must not be forwarded
 upstream (whereas "no" simply means that it has not yet been done).
 
-  * `Author` (optional)
+  * `Author` or `From` (optional)
 
 This field can be used to record the name and email of the patch author
 (ex: "`John Bear `"). Its usage is recommended when the
@@ -153,7 +160,7 @@ vendor).
 chance of being integrated upstream. This field can be used multiple
 times if several people authored the patch.
 
-  * `Reviewed-by` (optional)
+  * `Reviewed-by` or `Acked-by` (optional)
 
 This field can be used to document the fact that the patch has been
 reviewed by someone. It should list her name and email in the standard
@@ -171,7 +178,13 @@ Sample DEP-3 compliant headers
 
 A patch cherry-picked from upstream:
 
-Description: Fix regex problems with some multi-bytes characters
+From: Ulrich Drepper 
+Subject: Fix regex problems with some multi-bytes characters
+
+* posix/bug-regex17.c: Add testcases.
+* posix/regcomp.c (re_compile_fastmap_iter): Rewrite COMPLEX_BRACKET
+  handling.
+
 Origin: upstream, 
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bdb56bac
 Bug: http://sourceware.org/bugzilla/show_bug.cgi?id=9697
 Bug-Debian: http://bugs.debian.org/510219
@@ -216,3 +229,8 @@ Changes
 * 2009-08-24: Add samples and mention difference with RFC-2822 related to
   the Description field.
 * 2009-09-07: Move to CANDIDATE status.
+* 2009-09-26: Modified structure to allow for 2 set of fields (headers and
+  pseudo-headers). Make Subject an alias of Description, From an alias of
+  Author and Acked-by an alias of Reviewed-by. All those changes allow for
+  a better compatibility with patches that are VCS changesets embedded in
+  mails (notably those generated by git format-patch).

-- 
Raphaël Hertzog


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

Re: The future of the boot system in Debian

[Henrique de Moraes Holschuh]

On Sat, 26 Sep 2009, Russell Coker wrote:
> On Mon, 7 Sep 2009, Gabor Gombas  wrote:
> > The original announcement said that Fedora is already using upstart.
> > AFAIK Fedora is also commited to using SELinux. Do they use a similar
> > patch? Can they help convincing upstream?
> 
> In terms of the upstream SE Linux developers there is a difference of opinion 
> as to the best way to do some things.  Manoj and I have some different 
> priorities (such as supporting people who don't want to use initrd and 
> systems that can't use initrd) to the other upstream developers.

For which I am very grateful.  The backlash against über-fragile and
over-complex boot environments has already started, and you could see it
really well in LKML (refer for the tmpdevfs threads, for example).
RedHat's initrd has often been refered to with strong words there, I
don't think we should commit to *requiring* something like that.

Also, RedHat could care less for the smaller boxes, they don't optimize
for anything that doesn't have hardware RAID.  That's fine for RHEL user
demographics, but we're not like that, our user demographic is not like
that, and our values are not in perfect sync with theirs.  What's good
for RedHat is not necessarily good for Debian.

IME, simple initrds that don't really impact on your hability to boot
are fine (and great to load firmware, CPU microcode and kernel modules),
but anything else (like root on lvm or on non-auto-started md arrays)
will cause trouble sooner or later.

It is great that in Debian, no-initrd or simple-initrd setups are only a
simple kernel-compile away (you just need to do away with some
modularity).  We shouldn't lose this flexibility over RedHat's
priorities.

> This issue essentially is, do we do what Red Hat does and refuse to support 
> the people that Red Hat doesn't support - or do we do things our own way?  

Please don't.  We should retain our independence, and do things our own way
since it is obvious that RedHat is taking shortcuts that are not good for
us.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Fixing the Gobject Introspection mess

[Sebastian Dröge]

Am Samstag, den 26.09.2009, 11:54 +0200 schrieb Josselin Mouette:
> Le samedi 26 septembre 2009 à 07:56 +0200, Sebastian Dröge a écrit : 
> > Am Freitag, den 25.09.2009, 13:32 +0200 schrieb Josselin Mouette:
> > > 1. Package layout
> > > 
> > > GObject-introspection packages provide introspection data
> > > in /usr/share/gir-1.0/Foo-X.Y.gir, and the
> > > optional /usr/lib/girepository-1.0/Foo-X.Y.typelib.
> > >
> > > The packages should be architecture-dependent.
> > 
> > Only the typelib file actually is meant to be architecture-dependent
> > (right, the GIR file could be arch-dep too if the headers and API parts
> > of the sources (GObject properties/signals) are different from arch to
> > arch. But who does that?!).
> 
> This has already happened, and this will happen again. For the same
> reason we make headers architecture-dependent, I think we should make
> GIR files the same.

Ok, with my proposal to put them into the -dev packages that is no
problem then ;)

> > Also the GIR file is only meant for build time things so it could simply
> > be placed in the -dev packages (as I've done so far).
> 
> There is no “build time” for interpreters. What do you mean exactly?

Interpreters should use the typelib file and not the GIR file. The GIR
file is meant for generating bindings (like the current Python/C++/C#
bindings) while the typelib file is meant to be used at runtime to
generated bindings on the fly.

> > Putting the typelib files in the shared library packages will create
> > conflicts for soname changes. Not good (I know I placed them there in
> > some packages). Creating a new package just for the typelib file is not
> > good either ;)
> 
> Agreed. We should probably mandate to always split the introspection
> files in a separate package.

So you would always put the GIR and typelib files into a single separate
package? Or only the typelib file? IMHO only the latter would make
sense, the GIR file can/should be in the -dev package, and if only
because of space savings.

If you meant the former, shall we also create separate packages for Vala
bindings? They're very similar to the GIR files but are also only needed
at build time ;)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Fixing the Gobject Introspection mess

[Josselin Mouette]

Le samedi 26 septembre 2009 à 13:12 +0200, Sebastian Dröge a écrit : 
> > There is no “build time” for interpreters. What do you mean exactly?
> 
> Interpreters should use the typelib file and not the GIR file. The GIR
> file is meant for generating bindings (like the current Python/C++/C#
> bindings) while the typelib file is meant to be used at runtime to
> generated bindings on the fly.

OK, then I agree the .gir file should go in a separate development
package.

But that will make dependency computation more difficult, since it will
have to be done from the .typelib file. Time to dig deeper into the
libgirepository API…

> So you would always put the GIR and typelib files into a single separate
> package? Or only the typelib file? IMHO only the latter would make
> sense, the GIR file can/should be in the -dev package, and if only
> because of space savings.

Yes, agreed.

-- 
 .''`.  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: The future of the boot system in Debian

[Russell Coker]

On Mon, 7 Sep 2009, Gabor Gombas  wrote:
> The original announcement said that Fedora is already using upstart.
> AFAIK Fedora is also commited to using SELinux. Do they use a similar
> patch? Can they help convincing upstream?

Sorry for the delay in responding.

In terms of the upstream SE Linux developers there is a difference of opinion 
as to the best way to do some things.  Manoj and I have some different 
priorities (such as supporting people who don't want to use initrd and 
systems that can't use initrd) to the other upstream developers.

The Red Hat employees who do upstream SE Linux work are only interested in 
supporting initrd use of SE Linux.  The way things work with nash seems to be 
slightly less inconvenient for them than some of the things that have been 
proposed for Debian.  If we were to adopt the Red Hat initrd system then some 
of the objections to implementing the other Red Hat early-boot ideas in 
Debian would be removed (but we would still have the issue of supporting 
systems without an initrd).

This issue essentially is, do we do what Red Hat does and refuse to support 
the people that Red Hat doesn't support - or do we do things our own way?  
Our own way in this instance being the way that SE Linux has worked in RHEL4, 
RHEL5, and all releases of Fedora apart from the last couple.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


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

Re: Fields used in packages

[George Danchev]

> George Danchev  writes:
> 
> > So, the question being: from where to start documenting and sorting
> > these out:  policy, dpkg/doc/, devref, wiki, blogs ;-), somewhere else.
> 
> Standardized fields should be documented in Policy.  Patches and
> contributions are definitely welcome.  (And personally, I think this
> should include Vcs-*.)

Okay, that sounds reasonable, provided all non-user-defined fields are 
standard, 
or otherwise illegal. Another standard field (i.e. non-X[BSC] ) I found is 
`Bugs'; seems they are hinting someone or something like BTS or LP, though I'm 
not exactly sure if it is good candidate for reuse [1]. I also sorted packages 
on per field basis [2] (most interesting fields, not all). 

I'd also like to collect some data and feedback first, then we can file bugs 
and 
hopefully create patches. For instance, where to document the user-defined 
fields: devref, wiki, not-documented anywhere, since they are not meant to be 
reused or it is quite unlikely.

[1] http://people.debian.org/~danchev/survey/sorted/Bugs
[2] http://people.debian.org/~danchev/survey/_index.html
(should be self-explanatory)

-- 
pub 4096R/0E4BD0AB 


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

Re: Fields used in packages

[Russ Allbery]

George Danchev  writes:

> Okay, that sounds reasonable, provided all non-user-defined fields are
> standard, or otherwise illegal. Another standard field (i.e. non-X[BSC]
> ) I found is `Bugs'; seems they are hinting someone or something like
> BTS or LP, though I'm not exactly sure if it is good candidate for reuse
> [1]. I also sorted packages on per field basis [2] (most interesting
> fields, not all).

Bugs is sort of an interesting case since there's no reason to ever
include it in a Debian package, but it's part of the package format and
people making packages for non-Debian distributions should be aware of
it.  reportbug honors it when directing bugs to a different BTS.

I wouldn't mind seeing it in Policy, although of course Debian packages
shouldn't use it since we want to use our BTS for everything and that's
the default.

-- 
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: DEP-3 update: Patch Tagging Guidelines

[Paul Wise]

Hmm, in the examples, I would expect that the Origin/Bug/Bug-Debian
fields would be before the Subject field. If they aren't then I would
have thought they were part of the long description.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: GObject introspection mini-policy, take 2

[Paul Wise]

2009/9/26 Josselin Mouette :

> 1. Directory layout
>
> GObject-introspection data is generally provided in two formats:
>      * XML format in /usr/share/gir-1.0/Foo-X.Y.gir
>      * binary format in /usr/lib/girepository-1.0/Foo-X.Y.typelib
...
> 6. Example
>
> Suppose that libfoo-2.0 is an API built on libbar-3.0. The libfoo-2.0
> source generates the following files, put in the following packages:
>        libfoo-2.0-3 /usr/lib/libfoo-2.0.so.3*
>        libfoo-2.0-dev /usr/lib/libfoo-2.0.so (and other usual stuff)
>        libfoo-2.0-dev /usr/share/gir-1.0/Foo-2.0.gir
>        gir1.0-foo-2.0 /usr/lib/girepository-1.0/Foo-2.0.typelib

Would this proposal need to be adjusted for multiarch support?

If so, perhaps just insert an arch triple?

 /usr/lib//girepository-1.0/Foo-2.0.typelib

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Fields used in packages

[Paul Wise]

On Sun, Sep 27, 2009 at 3:26 AM, Russ Allbery  wrote:

> Bugs is sort of an interesting case since there's no reason to ever
> include it in a Debian package, but it's part of the package format and
> people making packages for non-Debian distributions should be aware of
> it.  reportbug honors it when directing bugs to a different BTS.
>
> I wouldn't mind seeing it in Policy, although of course Debian packages
> shouldn't use it since we want to use our BTS for everything and that's
> the default.

Sounds like it should be something documented in policy.

lintian already complains about it:

http://lintian.debian.org/tags/redundant-bugs-field.html

I'm wondering why it is overriden by dpkg, any ideas?

dpkg also overrides the Origin field, which is also strange.

http://lintian.debian.org/tags/redundant-origin-field.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Fields used in packages

[Russ Allbery]

Paul Wise  writes:

> Sounds like it should be something documented in policy.

> lintian already complains about it:

> http://lintian.debian.org/tags/redundant-bugs-field.html

> I'm wondering why it is overriden by dpkg, any ideas?

> dpkg also overrides the Origin field, which is also strange.

> http://lintian.debian.org/tags/redundant-origin-field.html

When I asked the dpkg developers about that, I think the answer was that
dpkg's use was intended as an example of correct use.

-- 
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: Fields used in packages

[George Danchev]

> George Danchev  writes:
> 
> > Okay, that sounds reasonable, provided all non-user-defined fields are
> > standard, or otherwise illegal. Another standard field (i.e. non-X[BSC]
> > ) I found is `Bugs'; seems they are hinting someone or something like
> > BTS or LP, though I'm not exactly sure if it is good candidate for reuse
> > [1]. I also sorted packages on per field basis [2] (most interesting
> > fields, not all).
> 
> Bugs is sort of an interesting case since there's no reason to ever
> include it in a Debian package, but it's part of the package format and
> people making packages for non-Debian distributions should be aware of
> it.  reportbug honors it when directing bugs to a different BTS.
> 
> I wouldn't mind seeing it in Policy, although of course Debian packages
> shouldn't use it since we want to use our BTS for everything and that's
> the default.

Candidates for policy so far:
http://people.debian.org/~danchev/survey/sorted/4policy
(Multi-Arch field added)

To be corrected to use Vcs-* (I'll file bugs further):
http://people.debian.org/~danchev/survey/sorted/X-Vcs-Browser
http://people.debian.org/~danchev/survey/sorted/X-Vcs-Svn

The rest are user-defined fields (X[SBC]) which are possible candidates to be 
documented in devref or wiki.d.o, since they seem more volatile to me:
http://people.debian.org/~danchev/survey/sorted/
However, I couldn't be precisely sure about the intentions of their creators, 
possible values, and parties supposed to honor or consume them as well.

-- 
pub 4096R/0E4BD0AB 


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

Re: Fields used in packages

[Russ Allbery]

George Danchev  writes:

> Candidates for policy so far:
> http://people.debian.org/~danchev/survey/sorted/4policy
> (Multi-Arch field added)

Oh, good, that's less than I thought there would be.  We should probably
add Origin as well.

> The rest are user-defined fields (X[SBC]) which are possible candidates to be 
> documented in devref or wiki.d.o, since they seem more volatile to me:
> http://people.debian.org/~danchev/survey/sorted/
> However, I couldn't be precisely sure about the intentions of their creators, 
> possible values, and parties supposed to honor or consume them as well.

Autobuild should probably go into Policy.  It's used for non-free packages
to indicate that it's legal for the buildds to build the packages.

Original-Maintainer is odd -- Ubuntu uses that for packages imported and
modified in Ubuntu, but I'm not sure what it's being used for in Debian.
It seems like it might be worth documenting, though.

I wonder what's up with all the Gstreamer and Npp fields.

-- 
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: Fields used in packages

[George Danchev]

> George Danchev  writes:
> 
> > Candidates for policy so far:
> > http://people.debian.org/~danchev/survey/sorted/4policy
> > (Multi-Arch field added)
> 
> Oh, good, that's less than I thought there would be.  

IMO, standardized fields (non-XBSC) are quite well documented in policy, and I 
didn't expected to find so much of it, however user-defined fields (XBSC) are 
not 
at all documented and couldn't be easily reused.

> We should probably
> add Origin as well.

Yeah, I added Origin to my `4policy' for now.

> > The rest are user-defined fields (X[SBC]) which are possible candidates to
> > be documented in devref or wiki.d.o, since they seem more volatile to me:
> > http://people.debian.org/~danchev/survey/sorted/
> > However, I couldn't be precisely sure about the intentions of their 
> > creators, 
> > possible values, and parties supposed to honor or consume them as well.
> 
> Autobuild should probably go into Policy.  It's used for non-free packages
> to indicate that it's legal for the buildds to build the packages.
> 
> Original-Maintainer is odd -- Ubuntu uses that for packages imported and
> modified in Ubuntu, but I'm not sure what it's being used for in Debian.
> It seems like it might be worth documenting, though.

Autobuild and Original-Maintainer are user-defined (XBSC) and I thought that 
policy should only mandate how user-defined fields are constructed as it does 
in 
#5.7. Concrete user-defined fields are subject to the user, eventually well 
documented so that can be reused by others. Make sense?

> I wonder what's up with all the Gstreamer and Npp fields.

These and Tads3-Version seem like a blatant abuse of user-defined fields 
mechanism to me.

-- 
pub 4096R/0E4BD0AB 


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

Re: Fields used in packages

[Russ Allbery]

George Danchev  writes:

>> Autobuild should probably go into Policy.  It's used for non-free
>> packages to indicate that it's legal for the buildds to build the
>> packages.
>> 
>> Original-Maintainer is odd -- Ubuntu uses that for packages imported
>> and modified in Ubuntu, but I'm not sure what it's being used for in
>> Debian.  It seems like it might be worth documenting, though.

> Autobuild and Original-Maintainer are user-defined (XBSC) and I thought
> that policy should only mandate how user-defined fields are constructed
> as it does in #5.7. Concrete user-defined fields are subject to the
> user, eventually well documented so that can be reused by others. Make
> sense?

Right, we'd do the same thing we did with Vcs-* and turn them into the
equivalent standardized fields without having them be user-defined.
Autobuild is special in that the archive software already pays attention
to a specific value.

Oh, what about Dm-Upload-Allowed?  I didn't see that on your list, but
surely there's a bunch of those?

-- 
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: Fields used in packages

[George Danchev]

> George Danchev  writes:
> 
> >> Autobuild should probably go into Policy.  It's used for non-free
> >> packages to indicate that it's legal for the buildds to build the
> >> packages.
> >> 
> >> Original-Maintainer is odd -- Ubuntu uses that for packages imported
> >> and modified in Ubuntu, but I'm not sure what it's being used for in
> >> Debian.  It seems like it might be worth documenting, though.
> 
> > Autobuild and Original-Maintainer are user-defined (XBSC) and I thought
> > that policy should only mandate how user-defined fields are constructed
> > as it does in #5.7. Concrete user-defined fields are subject to the
> > user, eventually well documented so that can be reused by others. Make
> > sense?
> 
> Right, we'd do the same thing we did with Vcs-* and turn them into the
> equivalent standardized fields without having them be user-defined.
> Autobuild is special in that the archive software already pays attention
> to a specific value.

Sure.
 
> Oh, what about Dm-Upload-Allowed?  I didn't see that on your list, but
> surely there's a bunch of those?

Aha, sure there is a lot of these, I just didn't put its output in sorted/ 
directory, since it is already available as general stats at:

http://people.debian.org/~danchev/survey/4.dm_upload_allowed

(I added Autobuild and Dm-Upload-Allowed to my 4policy record)

-- 
pub 4096R/0E4BD0AB 


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