Re: binutils-gold and symbols files

[Peter Fritzsche]

Michael Biebl wrote:
> As I received a couple of bug reports today about packages FTBFS, I
>  installed binutils-gold and tried to compile a few of my packages with it.
> 
> What I noticed is, that every package with symbols file, produced a lintian
> error, as binutils-gold added new symbols, the most common one was
> e...@base
> 
> What's the reason for those additional symbol(s) with binutils-gold?
Got response by the author and was a bug 
http://sourceware.org/bugzilla/show_bug.cgi?id=10876#c4

I had opened a bug #554852 in dpkg-dev but it is now closed again.

Best regards,
Peter


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

Re: DEP-5: binary package affected by license $foo

[Gunnar Wolf]

Frank Lin PIAT dijo [Wed, Nov 04, 2009 at 11:47:52PM +0100]:
> Exemple 2:
> > File: foo.c
> > License: GPL-2
> > Binary-Package: foo 
> > 
> > File: doc/info/*
> > License: GFDL-NON-FREE
> > Binary-Package: foo-doc-is-non-free
> The source package produces both a free and non-free package.
> 
> This extra header would be completely optional, and only useful to
> white-list some specific situation.
> 
> That's just an idea (a foolish idea?)

Leaving aside what Ben Finney and Robert Collins also replied to your
message... I do not believe this to be doable at all. 

Packages in main should have their source packages in main. But if the
source package has non-free components, then it cannot be uploaded
into main. Even if the non-free components are not packaged, in order
to be in main they need to be stripped out of said components (and,
say, repackaged with +dfsg version)

Of course, you could perfectly have source packages in main generating
binary packages both in main and in contrib - But the licenses for the
sources' components would all be GFDL-free anyway.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

[Alan Jenkins]

On 9/5/09, Petter Reinholdtsen  wrote:
>
> The future of the boot system in Debian
> ===
...
body omitted; see 
...
> Petter Reinholdtsen, Kel Modderman, Armin Berres
>

Thanks for the informative announcement.

I am curious about this specific proposal -

> change the init.d script
> handling to treat upstart jobs as init.d scripts, to provide an
> alternative for architectures lacking upstart support

I read this as a euphemism for non-linux architectures such as
kFreeBSD.  But I don't understand how this would be done.

I don't believe there is a bijection between upstart scripts and
traditional System V init scripts.  To take one example, an essential
feature is to discover the PID for each daemon, so that it can be
stopped if requested.  Upstart automatically determines daemon pids,
with directives such as "expect fork" (which uses ptrace()).
Traditional init scripts use different mechanisms, usually a pidfile.
It seems that maintaining both alternatives would require either a
hefty abstraction layer or a substantial amount of duplication.

An alternative would be to make upstart more portable.  At the moment
the only obvious technical problem is the use of ptrace(), but I don't
see this as insurmountable.  I think the biggest problem would be to
persuade upstream.

I'm prepared to work on the code... if it's really feasible, it
shouldn't take too long.  What I can't do is make a solid case to
upstream by myself.  It would really need agreement from the debian
upstart maintainers that this is their preferred way forward, along
with a commitment that Debian will help resolve any portability issues
which arise in future versions of upstart.

Does this make any sense?  Is anyone already working on running
upstart scripts on non-linux architectures?

Regards
Alan


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

Possible MBF wrt common, FHS-compliant, default document root for the various web servers

[Jan Hauke Rahm]

On Thu, Nov 05, 2009 at 04:39:06PM +0100, Stefano Zacchiroli wrote:
> On Thu, Nov 05, 2009 at 10:21:48AM +0100, Jan Hauke Rahm wrote:
> > Okay, I understand. Now, I see two ways actually to solve this.
> > 
> > 1. If we have a generic location for packages to drop their
> >html/php/whatever files, like /var/lib/www, all web servers can keep
> >their DocRoot as /var/www and provide an alias for /var/lib/www, for
> >instance /debian. That way webapp packages don't even have to care
> >about the web server in charge, we don't need a webapps-common, we
> >just need all web servers to provide that alias (or if they can't,
> >they have to symlink it). Every webapp would be available at
> >localhost/debian/webapp. Since it's either a symlink or a conffile
> >that makes this /debian alias, it can be changed by the local
> >sysadmin without any risks and without touching our packages data.
> > 2. If however all packages put their files in different locations, we
> >need your suggested solution with scripts for each webserver. A
> >package like webapps-common could run
> >foreach server in /usr/share/webapps-common/webservers/*; do
> >   ./$server webappPath webappName
> >done
> >and the web servers provide aliases/symlinks accordingly.
> > 
> > So, what's wrong with (1) that we don't go this simple path?
> 
> Fair question.  As I can't came up with an answer, I guess that (1) is
> indeed a better solution, due Occam's razor.
> 
> I only have a couple of remarks on some details:
> 
> - According to FHS, /var/lib/ is for "variable state information". As we
>   are talking about static HTML content, which only change upon package
>   upgrade, I believe it would not be appropriate. A better place would
>   probably be /usr/share/www/PACKAGE/ (maybe some FHS guru can give us
>   some insights here ...)

Full ack, and I even like /usr/share/www. It's easy to understand and 
pretty unprobable that we'd have a package called www in the archive
some day needing this location.

> - Regarding the URL that would be mapped to that dir, I don't
>   particularly like /debian/ (even though I've advanced it). However the
>   alternative solutions I can come up with (e.g. /packages/) are
>   actually uglier. So I guess /debian/ can stay. Some of the -webapps
>   people can probably come up with wiser suggestions ...

Manoj suggested '/vendor-apps' and I like that. It says what it should
say and doesn't steal any probable path.

I still see a problem with the upgrade path for existing installations.
I might be wrong but I think the most difficult cases are very custom
setups with lots of changes by the local admin. I'm thinking of e.g.
webmail.domain.tld being a virtual host with DocRoot
/usr/share/squirrelmail. If the files there move to
/usr/share/www/squirrelmail we break a lot of setups. So, what about
shipping a symlink from the old location to the new one as a migration
path? This doesn't solve the very default (e.g. users accessing
squirrelmail via localhost/squirrelmail) but that is so easily solved
via alias directive or symlink that I suppose a NEWS.Debian entry would
fit best here.
What do you say?

Now, I'm willing to run this, i.e. file bugs against web servers, wait
for them to be fixed, then file bugs against web applications (if
needed, I'm right now looking into a way to make a lintian check for it,
e.g. package-with-section-web-but-no-files-in-canonical-docroot). But I
don't feel like we're having a clear consensus here, do we?

Attached is a suggestion for MBF as well as a dd-list of all relevant
web servers (if I did my job right).

Now critizise!
Hauke
Subject: Install alias '/vendor-apps' to /usr/share/www as canonical DocRoot 
for packaged web applications
Package: apache2
Severity: wishlist
User: j...@debian.org
Usertags: canonicaldocroot-server

Dear maintainer,

when discussing the appropriate location for web application files it
was suggested to have one canonical location for those in the file
system that all these web applications should use. All web servers in
the archive should support this decision by providing a default way to
access this location.

It is consensus in debian-de...@l.d.o that this location shall be
/usr/share/www
and packages are supposed to drop their files in subdirectories, i.e.
/usr/share/www/package

(If a web application additionally needs files that are auto-generated
and/or to be touched by local admins or users, the application itself
should cope with that and provide a proper location for that, i.e.
probably '/var/lib/package/html' or similar.)

As a default this location shall be accessable via
http://localhost/vendor-apps/package

If this web server has an alias functionality it is best to use that as
conffiles are the easiest way for admins to adjust the setup to their
needs. If, however, such a functionality is not given, a symlink
/var/www/vendor-apps -> /usr/share/www
may solve the problem.

If

Re: Possible MBF wrt common, FHS-compliant, default document root for the various web servers

[Charles Plessy]

Le Sat, Nov 07, 2009 at 03:23:22PM +0100, Jan Hauke Rahm a écrit :
> 
> I still see a problem with the upgrade path for existing installations.
> I might be wrong but I think the most difficult cases are very custom
> setups with lots of changes by the local admin. I'm thinking of e.g.
> webmail.domain.tld being a virtual host with DocRoot
> /usr/share/squirrelmail. If the files there move to
> /usr/share/www/squirrelmail we break a lot of setups. So, what about
> shipping a symlink from the old location to the new one as a migration
> path? This doesn't solve the very default (e.g. users accessing
> squirrelmail via localhost/squirrelmail) but that is so easily solved
> via alias directive or symlink that I suppose a NEWS.Debian entry would
> fit best here.
> What do you say?

Dear Hauke,

As a maintainer of a web application, I share your worries. I never had any
user request to make it work out of the box with alternative web servers, so I
guess that my users have nothing to gain and everything to lose in a change. I
strongly suggest that the transition is experimented on a few volunteer
packages before increasing the workload of many persons – users and developers.

For new packages, grouping everything in /usr/share/www sounds like a good
idea.  The alias name, « vendor », I find a bit disturbing because we do not
sell anything. But picking the name will be the priviledge of the Do-o-crat who
will lead the transition, I presume.

Still, having /usr/share/www as a document root does not prevent complex
packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/,
/var/tmp, /var/run and /etc. Maybe you can double-check how many web servers
are able to cope with that before starting to invest a lot of time. Otherwise,
since shipping configuration files in /etc/webserver/conf.d will still be
necessary for these packages to work, there will little benefit in moving files
to /usr/share/www.

Anyway, thank you very much for your initiative. Exploring new directions is 
good !

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: DEP-5: binary package affected by license $foo

[Charles Plessy]

Le Wed, Nov 04, 2009 at 11:47:52PM +0100, Frank Lin PIAT a écrit :
> 
> Exemple 1:
> > File: doc/info/*
> > License: GFDL-NON-FREE
> > Binary-Package: none
> The package contains a file covered by a not-so-free license, but
> that file isn't used to build the binary file. And the file isn't
> shipped in the binary files.
> 
> 
> Exemple 2:
> > File: foo.c
> > License: GPL-2
> > Binary-Package: foo 
> > 
> > File: bar.c
> > License: GPL-3
> > Binary-Package: bar 
> The source package contains some files covered by two incompatible
> license, but it isn't a problem because the binary aren't combined at
> build nor at link time (or example).
> 
> Exemple 2:
> > File: foo.c
> > License: GPL-2
> > Binary-Package: foo 
> > 
> > File: doc/info/*
> > License: GFDL-NON-FREE
> > Binary-Package: foo-doc-is-non-free
> The source package produces both a free and non-free package.

Hello Frank,

I think that we are still far from producing copyright files specific to binary
packages, but definitely, let's be careful to not close doors, and if we can
open some at low cost it is welcome of course. Also, there is nothing in the
Policy that prevents maintainers to start doing this with their package if
they feel like experimenting:

  Every package must be accompanied by a verbatim copy of its copyright and
  distribution license in the file /usr/share/doc/package/copyright. This file
  must neither be compressed nor be a symbolic link. 

My understanding is that if source package S produces binary packages A and B,
/usr/share/doc/B/copyright does not need to describe the copyright of the files
in A.

This said, I think that we must care that copyright files are equally readable
by humans and machines, and easy to produce. So even if the field you propose
is optional, I think we need to consider how the copyright file would look like
if its use were widespread. Also, maybe we can acheive a similar result without
the using a new field, with an appropriate combination of control sums and
helper files.

Such a system could become a good safeguard against the inclusion of files that
are not free in the wrong package. Note that it is not an issue for the moment
as 1) non-free files are not allowed in the source packages, and 2) a source
package in main can not produce a binary package for contrib or non-free. The
field you propose could be an instrument for changing this, but I am affraid it
is not on the agenda, and is not likely to become so in the near future (even
if I would love to).

In summary, I think that your proposition is quite ahead of its time, but I 
would
have nothing against a ‘Future directions’ addendum to DEP-5 that would contain
such a field after it has been more throroughly thought.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: common, FHS-compliant, default document root for the various web servers

[Tzafrir Cohen]

On Fri, Nov 06, 2009 at 06:53:32PM -0600, Manoj Srivastava wrote:
> On Fri, Nov 06 2009, The Fungi wrote:
> 
> > On Fri, Nov 06, 2009 at 01:11:47PM +0100, Harald Braumann wrote:
> >> /debian/ seems to be the de facto standard for Debian archives. So I
> >> guess it wouldn't be such a good idea to use it for something else
> >> (sorry, can't really come up with a better name myself). 
> >
> > Something short, generic and distro-neutral like /app/ would be my
> > personal preference if I were developing a standard for my servers.
> > Unfortunately, going that direction as also increases the chances of
> > remapping a path the admin was already using...
> 
> /vendor-apps/ ?

"To see your locally-installed documentation, use:

  http://localhost/vendor-apps/dwww
"

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


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

Re: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

[Guillem Jover]

Hi!

On Sat, 2009-11-07 at 14:00:23 +, Alan Jenkins wrote:
> On 9/5/09, Petter Reinholdtsen  wrote:
> > change the init.d script
> > handling to treat upstart jobs as init.d scripts, to provide an
> > alternative for architectures lacking upstart support

> I read this as a euphemism for non-linux architectures such as
> kFreeBSD.  But I don't understand how this would be done.

> An alternative would be to make upstart more portable.  At the moment
> the only obvious technical problem is the use of ptrace(), but I don't
> see this as insurmountable.  I think the biggest problem would be to
> persuade upstream.

There's several others (taken from this thread [0]):

 * SIGPWR
 * inotify
 * waitid()
 * epoll, eventfd, signalfd, timerfd
 * ptrace
 * netlink proc connector
 * netlink udev interface

Check Scott's [1] and Petr's [2] mails on that thread for more details.

[0] 
[1] 
[2] 

> I'm prepared to work on the code... if it's really feasible, it
> shouldn't take too long.  What I can't do is make a solid case to
> upstream by myself.  It would really need agreement from the debian
> upstart maintainers that this is their preferred way forward, along
> with a commitment that Debian will help resolve any portability issues
> which arise in future versions of upstart.

The biggest issue I see is that someone will have to step up and
become “upstream” for the non-Linux ports, given Scott's position.
I'm not sure how he'd expect those to get released, if as outright
forks or something else, that'd need to be discussed with him. It will
also need copyright assignments [3] for the code that might need to be
merged back.

[3] 

> Does this make any sense?  Is anyone already working on running
> upstart scripts on non-linux architectures?

It was brought up in the debian-bsd list, but I don't know of any one
working on it.

regards,
guillem


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

Re: binutils-gold and symbols files

[Henrique de Moraes Holschuh]

On Fri, 06 Nov 2009, Peter Fritzsche wrote:
> The output of `ld -v 2` is "GNU gold (GNU Binutils for Debian 2.20) 1.9". So 
> it will catch the 1.9 here and just say "hey, i am sure that you are 
> evil" 
> which is of course wrong. So auto* stuff must be updated here. I will create 
> a 
> bug for libtool.

One is supposed to use Debian libtool, instead of whatever crap
(non-libtool) upstream added to the tarball, and this has been true for many
years, now.

Still, policy doesn't mandate that Debian libtool be used, and it will take
about 15 years or so to get all packages updated if you go the "let it
filter upstream" way ;-)

If that's a major problem for a complete switch to -gold, you may want to
keep that in mind.  Maybe we could mandate that all packages be
re-libtoolized before build, using Debian libtool... but I fear that will be
quite a lot of trouble.

-- 
  "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: Upstart on kFreeBSD? [was: The future of the boot system in Debian]

[Alan Jenkins]

On 11/7/09, Guillem Jover  wrote:
> Hi!
>
> On Sat, 2009-11-07 at 14:00:23 +, Alan Jenkins wrote:
>> On 9/5/09, Petter Reinholdtsen  wrote:
>> > change the init.d script
>> > handling to treat upstart jobs as init.d scripts, to provide an
>> > alternative for architectures lacking upstart support
>
>> I read this as a euphemism for non-linux architectures such as
>> kFreeBSD.  But I don't understand how this would be done.
>
>> An alternative would be to make upstart more portable.  At the moment
>> the only obvious technical problem is the use of ptrace(), but I don't
>> see this as insurmountable.  I think the biggest problem would be to
>> persuade upstream.
>
> There's several others (taken from this thread [0]):
>
>  * SIGPWR
>  * inotify
>  * waitid()
>  * epoll, eventfd, signalfd, timerfd
>  * ptrace
>  * netlink proc connector
>  * netlink udev interface
>
> Check Scott's [1] and Petr's [2] mails on that thread for more details.
>
> [0] 
> [1] 
> [2] 
>
>> I'm prepared to work on the code... if it's really feasible, it
>> shouldn't take too long.  What I can't do is make a solid case to
>> upstream by myself.  It would really need agreement from the debian
>> upstart maintainers that this is their preferred way forward, along
>> with a commitment that Debian will help resolve any portability issues
>> which arise in future versions of upstart.
>
> The biggest issue I see is that someone will have to step up and
> become “upstream” for the non-Linux ports, given Scott's position.
> I'm not sure how he'd expect those to get released, if as outright
> forks or something else, that'd need to be discussed with him. It will
> also need copyright assignments [3] for the code that might need to be
> merged back.
>
> [3] 
>
>> Does this make any sense?  Is anyone already working on running
>> upstart scripts on non-linux architectures?
>
> It was brought up in the debian-bsd list, but I don't know of any one
> working on it.
>
> regards,
> guillem

Thanks!
Alan


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

Re: binutils-gold and symbols files

[Peter Fritzsche]

Henrique de Moraes Holschuh wrote:
> On Fri, 06 Nov 2009, Peter Fritzsche wrote:
> > The output of `ld -v 2` is "GNU gold (GNU Binutils for Debian 2.20) 1.9".
> > So it will catch the 1.9 here and just say "hey, i am sure that you are
> > evil" which is of course wrong. So auto* stuff must be updated here.
> > I will create a bug for libtool.
> 
> One is supposed to use Debian libtool, instead of whatever crap
> (non-libtool) upstream added to the tarball, and this has been true for
>  many years, now.
> 
> Still, policy doesn't mandate that Debian libtool be used, and it will take
> about 15 years or so to get all packages updated if you go the "let it
> filter upstream" way ;-)
> 
> If that's a major problem for a complete switch to -gold, you may want to
> keep that in mind.  Maybe we could mandate that all packages be
> re-libtoolized before build, using Debian libtool... but I fear that will
>  be quite a lot of trouble.
Is this real the case? I have tried to libtoolize a package and it broke with:

libtool: Version mismatch error.  This is libtool 2.2, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2

Just copying libtool to that package worked, but maybe there are still some 
corner cases were this doesn't work. /usr/share/doc/cdbs/cdbs-doc.html for 
example /strongly/ discourage this.

Please understand me right. I don't have something against it, but  I don't 
know how to do it right and what autotool-gurus in Debian says about it.

Best regards,
Peter


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

Re: binutils-gold and symbols files

[Peter Fritzsche]

Peter Fritzsche wrote:
> Henrique de Moraes Holschuh wrote:
> > On Fri, 06 Nov 2009, Peter Fritzsche wrote:
> > > The output of `ld -v 2` is "GNU gold (GNU Binutils for Debian 2.20)
> > > 1.9". So it will catch the 1.9 here and just say "hey, i am sure that
> > > you are evil" which is of course wrong. So auto* stuff must be
> > > updated here. I will create a bug for libtool.
> >
> > One is supposed to use Debian libtool, instead of whatever crap
> > (non-libtool) upstream added to the tarball, and this has been true for
> >  many years, now.
> >
> > Still, policy doesn't mandate that Debian libtool be used, and it will
> > take about 15 years or so to get all packages updated if you go the "let
> > it filter upstream" way ;-)
> >
> > If that's a major problem for a complete switch to -gold, you may want to
> > keep that in mind.  Maybe we could mandate that all packages be
> > re-libtoolized before build, using Debian libtool... but I fear that will
> >  be quite a lot of trouble.
> 
> Is this real the case? I have tried to libtoolize a package and it broke
>  with:
> 
> libtool: Version mismatch error.  This is libtool 2.2, but the
> libtool: definition of this LT_INIT comes from an older release.
> libtool: You should recreate aclocal.m4 with macros from libtool 2.2
> 
> Just copying libtool to that package worked, but maybe there are still some
> corner cases were this doesn't work. /usr/share/doc/cdbs/cdbs-doc.html for
> example /strongly/ discourage this.
> 
> Please understand me right. I don't have something against it, but  I don't
> know how to do it right and what autotool-gurus in Debian says about it.
Ok, /usr/share/doc/autotools-dev/README.Debian.gz tells me about it. It 
doesn't mention a libtoolize just that it should be replaced. So I would 
say that this is a good way if the automake-dev maintaner says that it is the 
way to do.

As only some packages use the regex feature of libtool, only these packages 
must real update libtool after the bug #554821 is closed.

Best regards,
Peter


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

Re: binutils-gold and symbols files

[Henrique de Moraes Holschuh]

On Sat, 07 Nov 2009, Peter Fritzsche wrote:
> > Please understand me right. I don't have something against it, but  I don't
> > know how to do it right and what autotool-gurus in Debian says about it.
> Ok, /usr/share/doc/autotools-dev/README.Debian.gz tells me about it. It 
> doesn't mention a libtoolize just that it should be replaced. So I would 

autoreconf will update the entire auto* tools, as well as libtool and
gettext.

However, that will only work if the config files for the auto* tools are
clean and proper, and don't hit any forward-compatibility snags.

> As only some packages use the regex feature of libtool, only these packages 
> must real update libtool after the bug #554821 is closed.

This asks for a lintian check, maybe?

-- 
  "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: Possible MBF wrt common, FHS-compliant, default document root for the various web servers

[Jan Hauke Rahm]

Thanks for your response, Charles!

On Sun, Nov 08, 2009 at 12:09:28AM +0900, Charles Plessy wrote:
> As a maintainer of a web application, I share your worries. I never had any
> user request to make it work out of the box with alternative web servers, so I
> guess that my users have nothing to gain and everything to lose in a change. I
> strongly suggest that the transition is experimented on a few volunteer
> packages before increasing the workload of many persons – users and 
> developers.

I think this is a bit black or white. Users (ar rather admins) gain the
possibility to easily guess where a package is to be found. No looking
for /usr/share/package/html or something, just assume it's
/usr/share/www/package. And they don't lose everything, they just need
to read the chapter (yet to be written, of course) in the release notes
about web applications being moved; additionally NEWS.Debian should be
provided by any relevant package and so on.

Also, I said, a proper migration path has still to be figured out. The
question for now is: do we want this change at all and -- if so -- shall
I file bugs against the web servers. I'd suggest severity wishlist for
the start.

> For new packages, grouping everything in /usr/share/www sounds like a good
> idea.  The alias name, « vendor », I find a bit disturbing because we do not
> sell anything. But picking the name will be the priviledge of the Do-o-crat 
> who
> will lead the transition, I presume.

Well, I find 'vendor' a bit confusing as well but I'm not a native
english speaker and I don't have better ideas. Shoot if you have any.
Something like 'debian', 'webapps', 'applications' seem way to generic
for this.

> Still, having /usr/share/www as a document root does not prevent complex
> packages to be fragmented between /usr/share, /usr/lib/cgi-bin/, /var/lib/,
> /var/tmp, /var/run and /etc. Maybe you can double-check how many web servers
> are able to cope with that before starting to invest a lot of time. Otherwise,
> since shipping configuration files in /etc/webserver/conf.d will still be
> necessary for these packages to work, there will little benefit in moving 
> files
> to /usr/share/www.

And there isn't even a way we could (or want to) solve this.
Applications of many sorts have to deal with FHS, webapps are nothing
special in that matter. We can't allow an admin to fiddle aroung with
files in /usr/share, nor can we just pump all webapps into /var as this
will break (or at least bloat) many backup strategies and cause other
problems.

Until now I thought simple symlinks work with every webserver and thus
didn't see a problem for that. It's the application that sometimes needs
patching to deal with its being splattered around. Am I wrong here?

Hauke


signature.asc
Description: Digital signature

Bug#555006: ITP: libcloud -- a unified interface to the cloud

[Soren Hansen]

Package: wnpp
Severity: wishlist
Owner: Soren Hansen 


* Package name: libcloud
  Version : 0.1.1~git20091107
  Upstream Author : Alex Polvi 
* URL : http://www.libcloud.org/
* License : Apache2
  Programming Lang: Python
  Description : a unified interface to the cloud
libcloud is a pure Python client library for interacting with many of
the popular cloud server providers. It was created to make it easy for
developers to build products that work between any of the services that
it supports.
.
libcloud was originally created by the folks over at Cloudkick, but has
since grown into an independent free software project licensed under
the Apache License (2.0).



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

Re: common, FHS-compliant, default document root for the various web servers

[Charles Plessy]

Le Sat, Nov 07, 2009 at 04:16:54PM +, Tzafrir Cohen a écrit :
> 
> "To see your locally-installed documentation, use:
> 
>   http://localhost/vendor-apps/dwww
> "

Hello Tzafrir,

native Debian applications are actually the ones which have the least benefit
from this. I like a lot doc-central, because on computers with a short name,
only a few keystrokes in the browser bar can call it. Switching from “foo/dc”
to “foo/vendors-apps/dc” is unfun, expecially since the ‘-’ sign is a moving
target on heterogeneous keyboard environments.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Re: DEP-5: binary package affected by license $foo

[Paul Wise]

On Sat, Nov 7, 2009 at 11:19 PM, Charles Plessy  wrote:

> I think that we are still far from producing copyright files specific to 
> binary
> packages

There are already copyright files in binary packages that are
different to the source package debian/copyright; some of the source
packages I've created contain debian/copyright and
debian/foo.copyright because parts of the source package are not used
in the binary package. It isn't much of a stretch to put
debian/copyright, debian/foo.copyright and debian/bar.copyright.

-- 
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