Re: Request for Comments: Standardize enabling/disabling of system services

[Patrick Schoenfeld]

On Thu, Apr 02, 2009 at 12:07:25PM -0700, Steve Langasek wrote:
> On Thu, Apr 02, 2009 at 01:12:25PM +0200, Patrick Schoenfeld wrote:
> > On Wed, Apr 01, 2009 at 06:05:48PM -0700, Steve Langasek wrote:
> > > > I think that renaming and/or removing the init script symlinks is the
> > > > Right Thing To Do, but the tools we have for doing this are awful.  I
> > > > think it would be a great solution if update-rc.d gained the following
> > > > features:
> 
> > > I think this should be a separate program, reserving update-rc.d for
> > > maintainer script use.  But please, not 'chkconfig', which is an entirely
> > > unintuitive name. :)
> 
> > ACK. What speaks against 'service'? :)
> 
> If we use the name 'service', please also make it handle service
> starting/stopping, which is what the program of the same name is
> traditionally used for on Red Hat systems (and now on Ubuntu).

Makes sense. Yep.
 
> On Thu, Apr 02, 2009 at 06:26:26PM +0200, Luca Capello wrote:
> 
> > >> ACK. What speaks against 'service'? :)
> 
> > > Too generic? Maybe something like 'debserv' would be better, because 
> > > it's Debian specific.
> 
> > Maybe I am wrong, but since (most of) the Debian-specific tools to deal
> > with rc.d scripts end in -rc.d, why not 'service-rc.d'?
> 
> As already mentioned, I very much don't want these tools to be bound to
> sysv-rc, which I question the viability of in the long term.

Additional I thought 'WTF' when I read '... because it's Debian specific...'
because I really don't see a sense in that. Having tools for similar jobs do the
same on every system is really a step in the right direction to standardization.

Best Regards,
Patrick


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

Re: Request for Comments: Standardize enabling/disabling of system services

[Patrick Schoenfeld]

On Thu, Apr 02, 2009 at 12:41:20PM -0700, Steve Langasek wrote:
> > Indeed. Didn't think about the possibility of diversions. I guess
> > diverting the init scripts could be a solution (besides that it needs
> > some further work to the service managing utility). Then I'd
> > whole-heartedly agree with getting rid of RUN_* variables for the sake
> > of consistence.
> 
> Not diverting init scripts, only diverting update-rc.d and installing a
> wrapper around it.  Diverting init scripts would be full of fail.

Hm. In that case I think I don't understand your idea. You don't want to
divert update-rc.d just to pre-disable a certain service, do you?

Regards,
Patrick


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

Re: Re: DEP-4: The TDeb specification.

[Filipus Klutiero]

Neil Williams wrote:


On Tue, 31 Mar 2009 13:06:35 -0400
Filipus Klutiero  wrote:

> Neil Williams wrote:
> > Primary Motivations (in order):
> >1. Updates to translations should not require source NMU's.
> >   
> I guess that means avoiding to NMU with new diff.gz -s? If so, what are 
> the underlying motivations?


To prevent translation updates (particularly debconf ones) from
interfering with existing transitions and release cycles. There is no
need to rebuild the source of the package merely to update or add a new
translation. The current barriers to such rebuilds can be overcome with
adapted tools, as described in the DEP.

http://dep.debian.net/deps/dep4/#index10h2

There is no good reason to permit translation updates to cause the
binary packages to be changed by recompiling the source. Dependency
versions change, new bugs can be introduced, existing transitions get
more complicated and the one time when translation updates are most
useful is during a release freeze when the binaries must not change.
The whole point of i18n (the process of making a package support
localisation by internationalising the codebase) is to ensure that the
same compiled binary can operate with any compatible translation. This
allows users to set LANG= and get the localised version at runtime.
Requiring that translations can only be added or updated in Debian by
recompiling the source is a complete waste of effort and is something
that gettext and other l10n middle-ware are expressly designed to
avoid. Debian, currently, is simply not getting the best out of l10n
and is making life difficult for everyone by putting the translated
files in the same packages as the compiled binaries. Each release
cycle, this comes back to bite us. TDebs will remove this burden.
  
That would be a nice improvement, but let me suggest another 
implementation. To avoid introducing a second diff, why not updating the 
regular diff (in the case of non-native packages) but indicating that 
the package shouldn't be entirely rebuilt when uploading? This seems 
simpler.
> What is the purpose of creating a new binary package format for this (as 
> opposed to reusing, say, the deb format)?


To support easier management of the translations, including allowing
users to only install the translations that are needed for one
particular installation, instead of every user getting every
translation for every package they install, whether those translations
are even supported or not.
There are two ways to achieve this. One is per-language packages, the 
other is localization packages with multiple languages but using 
something like dpkg class support. Currently, the only way supported is 
language packages, but introducing a new package format will not 
necessarily allow the second way. Implementing this would take about the 
same amout of work as implementing something like dpkg class support for 
the deb file format.

 The current model is based on server
installations where lots of locales may be configured to support
localisation of web content. Installing all 90 locales does not
translate well to desktop installations with only a handful of users
and maybe 5 or 6 languages. On a typical Debian box, /usr/share/locale/
takes up 250Mb when each language only requires a maximum of 9Mb.
  
I'm not sure why you write that the current model is based on server 
installations. The current "model" I see is just the "natural" state of 
things, with no modularization WRT translations in the vast majority of 
packages. But yeah, it would be great to save this space.

TDebs are based on the .deb format, it is only a small change in the
organisation of the data.tar.gz but it simplifies various stages of
handling the resulting packages in the repository, in upload rules and
in other support tools.
Well, without details, I can't approve wholeheartedly, but if this isn't 
reinventing the wheel for no reason, the specification looks fine.



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

Re: Request for Comments: Standardize enabling/disabling of system services

[Steve Langasek]

On Fri, Apr 03, 2009 at 10:18:20AM +0200, Patrick Schoenfeld wrote:
> On Thu, Apr 02, 2009 at 12:41:20PM -0700, Steve Langasek wrote:
> > > Indeed. Didn't think about the possibility of diversions. I guess
> > > diverting the init scripts could be a solution (besides that it needs
> > > some further work to the service managing utility). Then I'd
> > > whole-heartedly agree with getting rid of RUN_* variables for the sake
> > > of consistence.

> > Not diverting init scripts, only diverting update-rc.d and installing a
> > wrapper around it.  Diverting init scripts would be full of fail.

> Hm. In that case I think I don't understand your idea. You don't want to
> divert update-rc.d just to pre-disable a certain service, do you?

Yes, I do.  Intercepting calls to a system tool to modify its behavior is a
common use case for dpkg diversions.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

[Daniel Leidert]

Ben Finney wrote:
> Raphael Geissert  writes:
> 
> > I planned to add support for svn in version 4 watch files (it would
> > be a matter of svn info svn://domain.tld/path/to/repo and some data
> > massaging).
> >
> > But well, now that everyone is talking about it why not just tell
> > what is missing so that it can be addressed in version 4 watch
> > files?

I would like to propose a complete rethinking of the watch files.
We have several packages, which must be prepared from a VCS or
must be repckaged. ATM several people changed to use something like

$url $pattern debian /bin/sh get-orig-source-script

One can't use

$url $pattern debian /usr/bin/make debian/rules get-orig-source

because make will error out because of the unknown switch
--upstream-version.

The next propblem is, that such a script doesn't have the same purpose
as uupdate has, as the first is used to create a new tarball and the
second to apply an existing diff to the new tarball.

So I was thinking about, how this could be solved. One idea, that came
to my mind is: Why not source debian/watch by uscan? One could then
write a watch file like this:

- first declare $url $pattern and maybe debian/uupdate like in the old
  watch file versions (probably this requires a new syntax, if
  debian/watch is sourced by the uscan script)

- then declare a function

sub prepare_orig_tarball () {
  ... the arguments should be upstream-version, debian-version,
  downloaded tarball name, orig-tarball name and ??? ...
  ... then add the commands to prepare/repack the tarball ...
}

uscan should then try, if this function exists, if not, simply download
the tarball/file specified by the pattern.

The function could simply contain a call like

/usr/bin/make debian/rules get-orig-source \
VERSION=$uvers PACKAGE=$orig_tarball

or call the already written get-orig-source script with the appropriate
arguments.

Opinions?

I'm pretty busy atm, but I would like to help fixing/improving uscan.

Regards, Daniel
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01


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

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

[Andreas Tille]

On Fri, 3 Apr 2009, Daniel Leidert wrote:


I would like to propose a complete rethinking of the watch files.
We have several packages, which must be prepared from a VCS or
must be repckaged. ATM several people changed to use something like

$url $pattern debian /bin/sh get-orig-source-script

One can't use

$url $pattern debian /usr/bin/make debian/rules get-orig-source

because make will error out because of the unknown switch
--upstream-version.


I used to work around this in my packages by providing a

debian/get-orig-source

script which is just called in the get-orig-source target of
debian/rules.  This might be a way to circumvent this specific
problem (nothing against rethinking in general for sure).


The next propblem is, that such a script doesn't have the same purpose
as uupdate has, as the first is used to create a new tarball and the
second to apply an existing diff to the new tarball.


Exactly - so my suggested workaround just solves the problem of
the "old way of thinking".


...
Opinions?


Interesting.

One additional thought: We store packaging Vcs and upstream homepage
in debian/control.  What about storing upstream Vcs there as well and
teach uscan to look there as well.  Just a rough thought.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: DEP-4: The TDeb specification.

[Neil Williams]

On Fri, 03 Apr 2009 04:21:59 -0400
Filipus Klutiero  wrote:

> That would be a nice improvement, but let me suggest another 
> implementation. To avoid introducing a second diff, why not updating the 
> regular diff (in the case of non-native packages) but indicating that 
> the package shouldn't be entirely rebuilt when uploading? This seems 
> simpler.

That breaks the existing source package in Debian - the .dsc referring
to that .diff.gz has been signed by the maintainer and any changes will
break that signature. TDebs are not related to source changes and
should not affect the existing source package. A TDeb upload needs to
sit alongside the existing files in the archive, not replace files
uploaded by the maintainer. This allows TDeb uploads during a release
freeze - even very late in a release cycle (which is the very time
that many debconf translations get updated currently).

> > > What is the purpose of creating a new binary package format for this (as 
> > > opposed to reusing, say, the deb format)?
> >
> > To support easier management of the translations, including allowing
> > users to only install the translations that are needed for one
> > particular installation, instead of every user getting every
> > translation for every package they install, whether those translations
> > are even supported or not.

> There are two ways to achieve this. One is per-language packages, the 
> other is localization packages with multiple languages but using 
> something like dpkg class support. Currently, the only way supported is 
> language packages, but introducing a new package format will not 
> necessarily allow the second way. Implementing this would take about the 
> same amout of work as implementing something like dpkg class support for 
> the deb file format.

? It's already implemented via a patch devised by Thomas Viehmann.
Sadly, due to other pressures, his tree on git.debian.org has been
removed.

> > TDebs are based on the .deb format, it is only a small change in the
> > organisation of the data.tar.gz but it simplifies various stages of
> > handling the resulting packages in the repository, in upload rules and
> > in other support tools.

> Well, without details, I can't approve wholeheartedly, but if this isn't 
> reinventing the wheel for no reason, the specification looks fine.

The DEP does describe the organisation of the data.tar.gz:
http://dep.debian.net/deps/dep4/#index5h2

Which details are missing from the DEP?

If you're actually asking to see the code, the changes were also put
into http://git.debian.org/?p=users/codehelp/dpkg.git;a=summary

However, I'm useless with git and my git 'thing' appears broken as far
as I can tell. I can't see how or why or how to fix it, so I'll update
the TDeb changes to the latest dpkg source next weekend and just stick
with patches or subversion - at least that works.

(Please, git-fanboys, don't start a sub-thread/flamewar abusing me for
my obvious idiocy in being unable to comprehend git - I hate it, I
apparently can't use it and I would simply prefer to actually get
things done without having to fight it.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpqF28fIeSlJ.pgp
Description: PGP signature

Bug#522396: RFP: rekonq -- KDE 4's lightweight QtWebkit based web browser

[Resul Cetin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: rekonq
Version: 0.0.4
Upstream Author: Andrea Diamantini 
URL: http://rekonq.sourceforge.net/
License: GPL2+
Description: KDE 4's lightweight QtWebkit based web browser

rekonq is a KDE browser based on QtWebkit. Its code is based on Nokia 
QtDemoBrowser, just like Arora. It integrates tightly into KDE 4 and process 
seperation for tabs like Chromium.



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

Re: Improvements to ‘debian/watch’ for fet ching from VCS

[Giacomo A. Catenazzi]

Ben Finney wrote:

Noah Slater  writes:


On Fri, Apr 03, 2009 at 10:04:21AM +1100, Ben Finney wrote:

* the plethora of different concepts for mapping identifiers to
  specific working trees in different VCSen (revision-id and branches
  and tags, oh my!)

This could be possible with a set of configurable rules, akin to make.

  get-recent:
  svn co http://example.org/ $DIR

  get-revision:
  svn co -r $REV http://example.org/ $DIR

As long as you standardised the variables passed, and the location,
should work.


That's the trouble though. AIUI, different VCSen have different ways
of identifying a specific state of the working tree; we have not only
revisions, but also tags, branches, threads, heads, and probably
others I've forgotten. Should all of those be allowed? Is that too
complex an interface?


What is $REV? How user know about a specific $REV? So I think
we need to parse the $REV, which we or upstream insert in changelog,
bug reports etc.  If user want more detailed use of $REV, it
should use the underlying VCS. I doubt that project use multiple
way to describe a revision.

[BTW: we should allow debian version (epoch and debian revision optional)
to $REV. Looking ad the version and/or changelog, the script should
attempt to find the mapper $REV, but without doing too hard.


As for “latest”: is there an unambiguous “latest” for every
repository? What does this mean with repositories that have
simultaneous lines of history within the same location?


latest stable? latest devel in a tree (python 2.x)? or
latest devel (sid like)?
It depends on package. A library with SONAME encoded in
package name has different need that a normal package

I think we should provide an helper, not the definitive
tool. So maintainer should have some control, and
user should expect that tools don't provide (or provide
a "old" source).

ciao
cate


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

Re: #522196 - RFP: gnu icecat - the GNU version of Mozilla Firefox

[Nico Golde]

Hi,
* Raphael Geissert  [2009-04-02 19:45]:
> [Security team BCC'ed]
> 
> Hi,
> 
> Do we really need another mozilla browser around?
> Last time I heard the iceweasel maintainers were looking for other people to 
> help them.
> 
> I don't think yet another clone of firefox is going to do any good in any 
> sense (including the security POV).

As providing security support for the ice* suite is already 
PITA and I see no reason why we should include this given 
that we have ice* I strongly oppose to include this to 
Debian.

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgp6kBQbMrZqS.pgp
Description: PGP signature

Re: #522196 - RFP: gnu icecat - the GNU version of Mozilla Firefox

[Mike Hommey]

On Fri, Apr 03, 2009 at 03:42:22PM +0200, Nico Golde  wrote:
> Hi,
> * Raphael Geissert  [2009-04-02 19:45]:
> > [Security team BCC'ed]
> > 
> > Hi,
> > 
> > Do we really need another mozilla browser around?
> > Last time I heard the iceweasel maintainers were looking for other people 
> > to 
> > help them.
> > 
> > I don't think yet another clone of firefox is going to do any good in any 
> > sense (including the security POV).
> 
> As providing security support for the ice* suite is already 
> PITA and I see no reason why we should include this given 
> that we have ice* I strongly oppose to include this to 
> Debian.

Actually, after talking to Giuseppe Scrivano (submitter of the RFP, and
icecat "upstream" maintainer), it appears icecat can be summarized
(implementation-wide) as a few preferences changes and an extension over
firefox/iceweasel, plus, obviously, branding.

If someone is interested in icecat in Debian, one can surely come up with
a nice small package on top of iceweasel (modulo branding, but it would be
nice to fix that in firefox upstream so that branding for iceweasel itself
would be easier, see the deb/iceweasel-rename branch of the iceweasel git
repo).

See #522331, too, for some ideas that could(should) go into iceweasel.

Mike


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

Re: #522196 - RFP: gnu icecat - the GNU version of Mozilla Firefox

[Brett Parker]

On 03 Apr 15:42, Nico Golde wrote:
> Hi,
> * Raphael Geissert  [2009-04-02 19:45]:
> > [Security team BCC'ed]
> > 
> > Hi,
> > 
> > Do we really need another mozilla browser around?
> > Last time I heard the iceweasel maintainers were looking for other people 
> > to 
> > help them.
> > 
> > I don't think yet another clone of firefox is going to do any good in any 
> > sense (including the security POV).
> 
> As providing security support for the ice* suite is already 
> PITA and I see no reason why we should include this given 
> that we have ice* I strongly oppose to include this to 
> Debian.

I thought they all now dynamically linked against xulrunner so that security
support was much simpler than before, so it's really just a frontend more than
a clone of firefox, no?

Cheers,
-- 
Brett Parker


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

Re: Again: Bug#503367: plink: file conflict with putty-tools

[Steffen Moeller]

Hello,

Daniel Leidert wrote:
> Andreas Tille wrote:
>> in October last year there was a longish discussion about name space
>> pollution regarding plink.  If you like to spend some time you should
>> read the complete log of #503367 [1].
>>
>> I decided to put an end now on this issue to make sure it will
>> not remain as is for ever and renamed the entry in /usr/bin.
>> This is explained in README.Debian of this package (see svn[2]).

we should ask the technical committee to rule over it. And maybe this
needs some voting in the end.

I personally think that we should not rename it. And putty's plink should not 
be renamed
either. The two are in a technical conflict, though with little practical 
consequences. To
me, this situation is preferable over the renaning of the binary of either.

Please keep in mind that we don't need to package everything. (sn)plink can 
just be
removed from the archive. Or could it move to non-free since it does not adhere 
to
Debian's principles? I need to reread the policy here.

Best regards,

Steffen


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

Re: Bug#522017: ITP: jblas -- jblas is a fast linear algebra library for Java

[Chris Walker]

Matthias Klose  writes:

> Chris Walker schrieb:
> > Soeren Sonnenburg  writes:
> > 
> >> Package: wnpp
> >> Severity: wishlist
> >> Owner: Soeren Sonnenburg 
> >>
> >> * Package name: jblas
> > 
> > This package seems likely to be of interest to debian-science, so I'm
> > sending this mail there too. 
> 
> if jblas seems to be of interest to debian-science, please would you take care

> of atlas and an upgrade to atlas 3.8 as well? else I would suggest to Chris to
> just go ahead and maybe CC debian-java.

When I said "jblas is of interest to debian-science", what I meant was
"I think that some of the people on debian-science may be interested
in jblas, so please keep them informed of your progress". In addition,
debian-science is a good place to ask for help with science applications. 

Chris


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

Re: Again: Bug#503367: plink: file conflict with putty-tools

[Andreas Tille]

On Fri, 3 Apr 2009, Steffen Moeller wrote:


we should ask the technical committee to rule over it. And maybe this
needs some voting in the end.


Who is this *we*?  Do you volunteer?
IMHO plink should be renamed because it is way less popular than the
putty tool.  So we will loose this voting anyway and there is much effort
for an foreseable outcome.  IMHO the solution I described in README.Debian
is reasonable for plink users even with existing scripts.


I personally think that we should not rename it. And putty's plink should not 
be renamed
either. The two are in a technical conflict, though with little practical 
consequences. To
me, this situation is preferable over the renaning of the binary of either.


This is a worse solution than a rename.


Please keep in mind that we don't need to package everything. (sn)plink can 
just be
removed from the archive. Or could it move to non-free since it does not adhere 
to
Debian's principles? I need to reread the policy here.


Moving to non-free will not solve the problem and is just wrong
(because it is actually not non-free).  Trying to solve a problem
by pretending wrong facts is a no go.

I'd strongly recommend to settle (together with upstream) for
a reasonable alternative name (I don't care whether it is
snplink, Plink, PLINK or something else) but we should find
a reasonable decision in a short time frame (to not spend to
power into an issue which does not bring anybody foreward).

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Bug#522017: ITP: jblas -- jblas is a fast linear algebra library for Java

[Dirk Eddelbuettel]

On 3 April 2009 at 07:51, Sylvestre Ledru wrote:
| Le vendredi 03 avril 2009   01:24 +0200, Matthias Klose a  crit :
| > Chris Walker schrieb:
| > > Soeren Sonnenburg  writes:
| > > 
| > >> Package: wnpp
| > >> Severity: wishlist
| > >> Owner: Soeren Sonnenburg 
| > >>
| > >> * Package name: jblas
| > > 
| > > This package seems likely to be of interest to debian-science, so I'm
| > > sending this mail there too. 
| > 
| > if jblas seems to be of interest to debian-science, please would you take 
care
| > of atlas and an upgrade to atlas 3.8 as well? else I would suggest to Chris 
to
| > just go ahead and maybe CC debian-java.
| I am currently working on atlas (see the work in the svn of pkg-scicomp)
| but it is a big work (especially solving the problem of the specific
| optimisation for each arch within the packaging system).

Allow to just budge in to say a heartfelt "Thank You"!  Debian always rocked
because of all the work Camm had done for Atlas, and it would be terrific if
we continued to have nicely working Atlas package.  So your work is really
appreciated!  

[ Personally speaking, I'd say feel free to simplify. IMHO it is better to
have a decent and current atlas-base (with a hook to optimise locally) than
a multitude of packages that invariably get old as cpu (sub-)architectures
change. ]

Dirk

-- 
Three out of two people have difficulties with fractions.


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

Re: DEP-4: The TDeb specification.

[Ian Jackson]

Neil Williams writes ("Re: DEP-4: The TDeb specification."):
> On Tue, 31 Mar 2009 13:06:35 -0400
> Filipus Klutiero  wrote:
> > What is the purpose of creating a new binary package format for this (as 
> > opposed to reusing, say, the deb format)?
> 
> To support easier management of the translations, including allowing
> users to only install the translations that are needed for one
> particular installation, instead of every user getting every
> translation for every package they install, whether those translations
> are even supported or not.

This would be easier to analyse if the reasoning behind the tdeb
specific changes was clearly explained.

Also, are we supposed to be reading this:
 http://dep.debian.net/deps/dep4/
or this:
 http://wiki.debian.org/i18n/TranslationDebs

I think rebuilding the whole package as a binNMU just because of a
translation change is something that should be avoided.  Translation
uploads should not be able to change non-translation content.

One problem that I think you need to address is the
/var/lib/dpkg/.list files.

Ian.


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

Re: Re: DEP-4: The TDeb specification.

[Filipus Klutiero]

On Fri, 03 Apr 2009 04:21:59 -0400
Filipus Klutiero  wrote:

> That would be a nice improvement, but let me suggest another 
> implementation. To avoid introducing a second diff, why not updating the 
> regular diff (in the case of non-native packages) but indicating that 
> the package shouldn't be entirely rebuilt when uploading? This seems 
> simpler.


That breaks the existing source package in Debian - the .dsc referring
to that .diff.gz has been signed by the maintainer and any changes will
break that signature.
  
Right - unless the .dsc is also updated. And if there is to be a tdiff, 
I don't see why .dsc-s wouldn't include the tdiff's digest.

TDebs are not related to source changes and
should not affect the existing source package. A TDeb upload needs to
sit alongside the existing files in the archive, not replace files
uploaded by the maintainer. This allows TDeb uploads during a release
freeze - even very late in a release cycle (which is the very time
that many debconf translations get updated currently).
  
That's the question. I don't see why adding a new diff would ease 
testing transition compared to updating the existing diff - given that 
the "traditional"/current binary packages aren't rebuilt when uploading 
translation updates.
> > > What is the purpose of creating a new binary package format for this (as 
> > > opposed to reusing, say, the deb format)?

> >
> > To support easier management of the translations, including allowing
> > users to only install the translations that are needed for one
> > particular installation, instead of every user getting every
> > translation for every package they install, whether those translations
> > are even supported or not.

> There are two ways to achieve this. One is per-language packages, the 
> other is localization packages with multiple languages but using 
> something like dpkg class support. Currently, the only way supported is 
> language packages, but introducing a new package format will not 
> necessarily allow the second way. Implementing this would take about the 
> same amout of work as implementing something like dpkg class support for 
> the deb file format.


? It's already implemented via a patch devised by Thomas Viehmann.
  

Great. Then it should be little work to implement the same for .deb.

[...]

> > TDebs are based on the .deb format, it is only a small change in the
> > organisation of the data.tar.gz but it simplifies various stages of
> > handling the resulting packages in the repository, in upload rules and
> > in other support tools.

> Well, without details, I can't approve wholeheartedly, but if this isn't 
> reinventing the wheel for no reason, the specification looks fine.


The DEP does describe the organisation of the data.tar.gz:
http://dep.debian.net/deps/dep4/#index5h2

Which details are missing from the DEP?
  
The data.tar.gz is correctly described, yes. The details I was referring 
to are the simplifications of "various stages of handling the resulting 
packages in the repository, in upload rules and in other support tools" 
you were talking about. These details don't need to be part of the 
specification, but could be somewhere in the DEP or in its presentation.

If you're actually asking to see the code, the changes were also put
into http://git.debian.org/?p=users/codehelp/dpkg.git;a=summary
  

No, I'm not asking to see the code...

[...]


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

Re: DEP-4: The TDeb specification.

[Neil Williams]

On Fri, 3 Apr 2009 18:46:48 +0100
Ian Jackson  wrote:

> Neil Williams writes ("Re: DEP-4: The TDeb specification."):
> > On Tue, 31 Mar 2009 13:06:35 -0400
> > Filipus Klutiero  wrote:
> > > What is the purpose of creating a new binary package format for this (as 
> > > opposed to reusing, say, the deb format)?
> > 
> > To support easier management of the translations, including allowing
> > users to only install the translations that are needed for one
> > particular installation, instead of every user getting every
> > translation for every package they install, whether those translations
> > are even supported or not.
> 
> This would be easier to analyse if the reasoning behind the tdeb
> specific changes was clearly explained.
> 
> Also, are we supposed to be reading this:
>  http://dep.debian.net/deps/dep4/

The DEP, please, yes.

I'll update the DEP with the answers to any questions that arise.

> or this:
>  http://wiki.debian.org/i18n/TranslationDebs

Ah, good point - that's a very old page so not that one. There is some
useful stuff on that so I don't think we should just remove the entire
thing or replace it with the DEP (defeats the point of the DEP to turn
it back into a wiki page with all problems of duplication).

I'll work on some edits tomorrow unless someone else takes the
opportunity.
 
> I think rebuilding the whole package as a binNMU just because of a
> translation change is something that should be avoided.  Translation
> uploads should not be able to change non-translation content.
> 
> One problem that I think you need to address is the
> /var/lib/dpkg/.list files.

Yes, that needs to be folded into the changes within dpkg so that when
a TDeb is installed, the actual filename installed on the system goes
into the /var/lib/dpkg/info/$package-tdeb.list file - the $package.list
file would already have had the relevant content removed because the
version of $package using the TDeb would not contain translated content.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpySx6tNr9YS.pgp
Description: PGP signature

Re: DEP-4: The TDeb specification.

[Neil Williams]

On Fri, 03 Apr 2009 16:45:46 -0400
Filipus Klutiero  wrote:

Please note:

All of the implementation details can wait until after Squeeze - all
that is needed for this release cycle is that apt and dpkg can handle a
migration from Squeeze to Squeeze+1 where packages being upgraded may
use TDebs for the debconf translations. There's quite enough work there
without trying to think beyond Squeeze into issues that may or may not
arise around how the actual TDebs that won't exist until after Squeeze
get handled by other tools not actually involved in allowing migrations
from Squeeze to Squeeze+1.

Please bear this in mind when discussing DEP-4 - I'll expand on the
current Timeline section of the DEP to include some clearer indications
of which stages get done when. (For those who want to know before I
make the update, it will be based on the timescales from my
presentation at Fosdem 2009, PDF and video available.)

http://www.emdebian.org/media/debian-media/slides/TDebs_draft_specification/

http://www.emdebian.org/media/debian-media/

> > > That would be a nice improvement, but let me suggest another 
> > > implementation. To avoid introducing a second diff, why not updating the 
> > > regular diff (in the case of non-native packages) but indicating that 
> > > the package shouldn't be entirely rebuilt when uploading? This seems 
> > > simpler.
> >
> > That breaks the existing source package in Debian - the .dsc referring
> > to that .diff.gz has been signed by the maintainer and any changes will
> > break that signature.

> Right - unless the .dsc is also updated. And if there is to be a tdiff, 
> I don't see why .dsc-s wouldn't include the tdiff's digest.

There will be a complementary dsc using the +t1 version suffix.
The .dsc uploaded by the maintainer cannot be updated without the
maintainer signing it again. However, this is an implementation issue
for after Squeeze.

> > TDebs are not related to source changes and
> > should not affect the existing source package. A TDeb upload needs to
> > sit alongside the existing files in the archive, not replace files
> > uploaded by the maintainer. This allows TDeb uploads during a release
> > freeze - even very late in a release cycle (which is the very time
> > that many debconf translations get updated currently).

> That's the question. I don't see why adding a new diff would ease 
> testing transition compared to updating the existing diff - given that 
> the "traditional"/current binary packages aren't rebuilt when uploading 
> translation updates.

The existing diff is not to be changed because that makes it easier to
be sure that we have the relevant source for the relevant binaries.
ftp-master made it clear at DebConf8 that the source package (the .dsc,
the .diff.gz and .orig.tar.gz or .tar.gz in the case of native
packages) was not to be touched by a TDeb upload. Changes made to
generate the TDeb go into +t1.diff.gz.

Joerg? Mark? Do you want to add some comments on that?

> > > > > What is the purpose of creating a new binary package format for this 
> > > > > (as 
> > > > > opposed to reusing, say, the deb format)?
> > > >
> > > > To support easier management of the translations, including allowing
> > > > users to only install the translations that are needed for one
> > > > particular installation, instead of every user getting every
> > > > translation for every package they install, whether those translations
> > > > are even supported or not.
> >
> > > There are two ways to achieve this. One is per-language packages, the 
> > > other is localization packages with multiple languages but using 
> > > something like dpkg class support. Currently, the only way supported is 
> > > language packages, but introducing a new package format will not 
> > > necessarily allow the second way. Implementing this would take about the 
> > > same amout of work as implementing something like dpkg class support for 
> > > the deb file format.
> >
> > ? It's already implemented via a patch devised by Thomas Viehmann.
> >   
> Great. Then it should be little work to implement the same for .deb.

Package management tools need a way to tell a .deb from a .tdeb - the
two need to be handled differently by tools like dak, britney, apt,
dpkg, reprepro, deb-gview and others.

> > The DEP does describe the organisation of the data.tar.gz:
> > http://dep.debian.net/deps/dep4/#index5h2
> >
> > Which details are missing from the DEP?
> >   
> The data.tar.gz is correctly described, yes. The details I was referring 
> to are the simplifications of "various stages of handling the resulting 
> packages in the repository, in upload rules and in other support tools" 
> you were talking about. These details don't need to be part of the 
> specification, but could be somewhere in the DEP or in its presentation.

Those are the bug reports that I need to start preparing but not
until after Squeeze. ;-)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarep

Bug#522454: ITP: protobuf -- Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.

[Ehren Kret]

Package: wnpp
Severity: wishlist
Owner: Ehren Kret 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: protobuf
  Version : 2.0.3
  Upstream Author : Kenton Varda , et al.
* URL : http://code.google.com/p/protobuf/
* License : New BSD License
  Programming Lang: C++, Python, Java
  Description : Protocol Buffers are a way of encoding structured data in 
an efficient yet extensible format.

Protocol buffers are a flexible, efficient, automated mechanism for
serializing structured data – think XML, but smaller, faster, and
simpler. You define how you want your data to be structured once, then
you can use special generated source code to easily write and read your
structured data to and from a variety of data streams and using a
variety of languages. You can even update your data structure without
breaking deployed programs that are compiled against the "old" format. 

- -- System Information:
Debian Release: lenny/sid
  APT prefers intrepid-updates
  APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 
'intrepid'), (50, 'jaunty')
Architecture: amd64 (x86_64)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknWeVYACgkQwfrgSb2kTTrJfgCgtYspXn7FO9GYYxARV8rUR/DB
WPUAmgNV+1gwDAvVK5qhZKgtS0PaOBrO
=P/Zl
-END PGP SIGNATURE-



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

Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Hi,

one of the changes in 3.8.1 was, that support for tmpfs on /var/run (and
/var/tmp) became mandatory [9.3.2]. Lintian is now also complaining very loudly
(error) if your package ships a directory in /var/run or /var/tmp and suggests
to create them in the init script.

While I can see the benefits of having /var/tmp on a tmpfs to a certain degree,
I don't really see them for /var/run, instead they make things more complicated,
slower and error prone (for imho no real gain)

1.) It's not the default on Debian anyway
2.) A lot of packages must be changed for this new policy
3.) You have to check for the directory on each boot, meaning wasted cpu cycles,
even if you don't use this feature (as said, its default is off on Debian)
4.) You have to manually cleanup in postrm. (I guess most packages will forget
that, leaving cruft around)
5.) If your package does not have an init script (I happen to maintain two such
packages), I now have to create init scripts simply to create a /var/run
directory. That's insane and even more wasting cpu cycles.

As I said, I don't see the benefit of a tmpfs for /var/run which would justify
this policy change so would very much appreciate to here valid reasons for this
change.

I also think, that the recommendation to remove the /var/run directories and
creating them manually on each boot in each package is the wrong approach.

For people, that want to use a tmpfs for /var/run, there could be a script on
shutdown which backups (or copies) the content of /var/run and restores it on
boot (the creation of this backup could also be triggered by a dpkg file system
trigger, which would eliminate of the backup being outdated because of a hard
reset. This would obviously only happen, if RAMRUN is set)

This way, people using the default (not tmpfs) would not get the performance hit
and we wouldn't have to modify a lot of packages.

So my suggestion is, to rework 9.3.2 and remove this requirement again.

And again, can someone please enlighten my, why tmpfs for /var/run is a good
idea anyway.


Thoughts, comments?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[Goswin von Brederlow]

Cyril Brulebois  writes:

> Vincent Fourmond  (01/04/2009):
>>   Although I admit that schroot is a neat tool to deal with that, it is
>> overkill in the case of wine, and much too complex for users that would
>> be interested to use wine: one of the public that can be attracted to
>> the GNU/Linux side of the game is gamers - especially now that there are
>> so many *recent* games that work with it. Telling them: «well, you'll
>> have to build a ia32 chroot to play...» is likely to drive them off for
>> good.
>
> I can't really see why wine couldn't embed a script to do the needed
> work. Users would need to call a single command to prepare the
> environment. It could, I guess, even be done in the postinst.
>
> Mraw,
> KiBi.

So wine on amd64 should be a dummy package that then creates a 32bit
chroot all on its own?

Now what about rar? Another chroot?

And what about all the 3rd party debs? They certianly won't provide a
"build me a chroot" debs.

Or what about changes in /etc/resolve.conf? Suddenly you need to run a
dns proxy so the chroot has internet access even if your dsl modem
redials and gets a new nameserver.


A 32 bit chroot is something a user can create but not something you
can package up reasonably clean.

MfG
Goswin


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

Re: Bug#522454: ITP: protobuf -- Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.

[Sune Vuorela]

On Friday 03 April 2009 23:02:28 Ehren Kret wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ehren Kret 
>
>
> * Package name: protobuf
>   Version : 2.0.3
>   Upstream Author : Kenton Varda , et al.
> * URL : http://code.google.com/p/protobuf/

http://packages.qa.debian.org/p/protobuf.html  ?

Though it looks like it could kind of need a hand.

> -- System Information:
> Debian Release: lenny/sid
>   APT prefers intrepid-updates
>   APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500,
> 'intrepid'), (50, 'jaunty') Architecture: amd64 (x86_64)

-- 
Genius, I cannot telnet from the BIOS bus on the port 5 to a password of the 
utility, how does it work?

First from ICQ or from the folder inside Netscape 8000 you should mount a AT X 
floppy disk and you have not to save the connector for renaming a Fast DLL 
driver to the printer.


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Michael Biebl  writes:

> 1.) It's not the default on Debian anyway

It is, however, a standard and supported option and it's the default in
Ubuntu.  The FHS is silent about directories in /var/run across reboots
but requires that all files in /var/run be deleted on reboot.

> 4.) You have to manually cleanup in postrm. (I guess most packages will forget
> that, leaving cruft around)

If you're creating any files in /var/run during the operation of the
package (and if not, why do you have a directory in /var/run in the first
place?), then you have to do this anyway, so this isn't new.  (Well, I
suppose you could just rely on the next reboot deleting them, but that
doesn't feel very clean and I'm not sure that's really in the spirit of
our requirements.)

> 5.) If your package does not have an init script (I happen to maintain
> two such packages), I now have to create init scripts simply to create a
> /var/run directory. That's insane and even more wasting cpu cycles.

Could you provide more details about what package without an init script
uses /var/run?  The only other case that I can think of is packages that
create transient UNIX-domain sockets.

> As I said, I don't see the benefit of a tmpfs for /var/run which would
> justify this policy change so would very much appreciate to here valid
> reasons for this change.

Did you already read the Policy bug?  It contains a rationale, although I
don't know if it's a complete enough one for you.

> For people, that want to use a tmpfs for /var/run, there could be a
> script on shutdown which backups (or copies) the content of /var/run and
> restores it on boot

I assume you mean only the directory structure?  Otherwise, this would be
an FHS violation.

Personally, I'm not inclined to revert this change.  I think it's correct
and continues to be correct, and I'd rather not undo the work that's
already been put into making it work.  This was added to Policy in part
because of various bug reports against packages not working as expected,
so removing it from Policy won't make those bug reports go away again.
And I think it's better to fix the packages than to add something to
preserve /var/run directories across boot, which seems like a hack to me.

-- 
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: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

[Raphael Geissert]

Andreas Tille wrote:
[...]
> 
> One additional thought: We store packaging Vcs and upstream homepage
> in debian/control.  What about storing upstream Vcs there as well and
> teach uscan to look there as well.  Just a rough thought.
> 

And do what with it? how will it know what it should look for? that's why
all that information is in and belongs to the watch files.

Cheers,
Raphael Geissert


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

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

[Raphael Geissert]

Ben Finney wrote:
[...]
> 
> For my purposes, I would like to be able to specify “fetch from the
> VCS at $URL, getting the specific working tree referenced by
> identifier $ID” and then the rest of what uscan does for generating
> an original source archive from the working tree.
> 
> That's made more complex, of course, by:
> 
> * the fact that the URL doesn't necessarily indicate what VCS tool is
>   needed to interact with it (just about all of them allow an HTTP URL
>   for public read-only access, so that's what will commonly be used
>   here)

That can easily solved, svn+http://...

> 
> * the plethora of different concepts for mapping identifiers to
>   specific working trees in different VCSen (revision-id and branches
>   and tags, oh my!)
> 

uscan would retrieve the information (say the output of svn info
svn://domain.tld/repo/) and match the rest of the pattern against the
output. Whataver is specified is what would uscan would svn export.

> Ideally this would be predicated on the Final and Definitive Interface
> to All VCSen Now and Future™, but I think that might be delayed by at
> least a month or so.
> 

s/month/decade?

Cheers,
Raphael Geissert



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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Russ Allbery wrote:
> Michael Biebl  writes:

Hi Russ

>> 1.) It's not the default on Debian anyway
> 
> It is, however, a standard and supported option and it's the default in

Hm, what standard exactly do you refer too.

> Ubuntu.  The FHS is silent about directories in /var/run across reboots
> but requires that all files in /var/run be deleted on reboot.
> 
>> 4.) You have to manually cleanup in postrm. (I guess most packages will 
>> forget
>> that, leaving cruft around)
> 
> If you're creating any files in /var/run during the operation of the
> package (and if not, why do you have a directory in /var/run in the first
> place?), then you have to do this anyway, so this isn't new.  (Well, I
> suppose you could just rely on the next reboot deleting them, but that
> doesn't feel very clean and I'm not sure that's really in the spirit of
> our requirements.)

Not really. Say you have a pretty standard system daemon
When the daemon is stopped in postinst, the pid file will be automatically
deleted and dpkg will cleanup the remaining /var/run/$foo directory.

>> 5.) If your package does not have an init script (I happen to maintain
>> two such packages), I now have to create init scripts simply to create a
>> /var/run directory. That's insane and even more wasting cpu cycles.
> 
> Could you provide more details about what package without an init script
> uses /var/run?  The only other case that I can think of is packages that
> create transient UNIX-domain sockets.

policykit is such an example. Potentially as D-Bus system bus activated system
services are affected by this, because they (usually) don't ship any init 
script.

We will se such services more and more in the future (like it or not).

>> As I said, I don't see the benefit of a tmpfs for /var/run which would
>> justify this policy change so would very much appreciate to here valid
>> reasons for this change.
> 
> Did you already read the Policy bug?  It contains a rationale, although I
> don't know if it's a complete enough one for you.

I just skimmed over the bug report.
And I think it completely misses to justify, why it is a good idea to have tmpfs
on /var/run.
I provided a list of cons of tmpfs (you could probably also add, that it breaks
selinux). Is there actually a list of pros?



>> For people, that want to use a tmpfs for /var/run, there could be a
>> script on shutdown which backups (or copies) the content of /var/run and
>> restores it on boot
> 
> I assume you mean only the directory structure?  Otherwise, this would be
> an FHS violation.

Right, only the directories. would be as simple as tar -cpf /tmp/foo.tgz $(find
-type d)

> Personally, I'm not inclined to revert this change.  I think it's correct
> and continues to be correct, and I'd rather not undo the work that's
> already been put into making it work.  This was added to Policy in part
> because of various bug reports against packages not working as expected,
> so removing it from Policy won't make those bug reports go away again.
> And I think it's better to fix the packages than to add something to
> preserve /var/run directories across boot, which seems like a hack to me.

Not more of a hack than adding init scripts which do nothing else then creating
/var/run/foo, with the added benefit that only the users (minority) which
actually use RAMRUN would have to live with this "hack".

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Michael Biebl wrote:
> Russ Allbery wrote:
>> Michael Biebl  writes:

>>> 5.) If your package does not have an init script (I happen to maintain
>>> two such packages), I now have to create init scripts simply to create a
>>> /var/run directory. That's insane and even more wasting cpu cycles.
>> Could you provide more details about what package without an init script
>> uses /var/run?  The only other case that I can think of is packages that
>> create transient UNIX-domain sockets.
> 
> policykit is such an example. Potentially as D-Bus system bus activated system
^^
all
> services are affected by this, because they (usually) don't ship any init 
> script.
> 

Another class of services which might be affected, are daemons/programs started
by inetd.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Michael Biebl  writes:
> Russ Allbery wrote:

>> It is, however, a standard and supported option and it's the default in
> 
> Hm, what standard exactly do you refer too.

standard, adjective [1622]

   2) (a) regularly and widely used, available, or supplied   (b) well-established and very familiar  

is what I meant.  /var/run on tmpfs has been common on UNIX platforms for
many years.  It was standard on Solaris at least as far back as Solaris 8,
for example.

-- 
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: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Michael Biebl  writes:

> Another class of services which might be affected, are daemons/programs
> started by inetd.

Why would they put anything in /var/run?

-- 
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: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

[Raphael Geissert]

[No CC please]

Daniel Leidert wrote:
[...]
> 
> I would like to propose a complete rethinking of the watch files.
> We have several packages, which must be prepared from a VCS or
> must be repckaged. ATM several people changed to use something like
> 
> $url $pattern debian /bin/sh get-orig-source-script
> 
> One can't use
> 
> $url $pattern debian /usr/bin/make debian/rules get-orig-source
> 
> because make will error out because of the unknown switch
> --upstream-version.
> 

Sure, that's something that could be modified in version 4 watch files. I'm
thinking about a format string a-la printf.

> The next propblem is, that such a script doesn't have the same purpose
> as uupdate has, as the first is used to create a new tarball and the
> second to apply an existing diff to the new tarball.
> 
> So I was thinking about, how this could be solved. One idea, that came
> to my mind is: Why not source debian/watch by uscan? One could then
> write a watch file like this:
> 

I'm against sourcing anything, this is far beyond the pourpose of the watch
files and can be done by a specified helper script.

Cheers,
Raphael Geissert



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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Russ Allbery wrote:
> Michael Biebl  writes:
> 
>> Another class of services which might be affected, are daemons/programs
>> started by inetd.
> 
> Why would they put anything in /var/run?
> 

I guess for the same reasons why other system daemons put stuff in /var/run

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Russ Allbery wrote:
> Michael Biebl  writes:
>> Russ Allbery wrote:
> 
>>> It is, however, a standard and supported option and it's the default in
>> 
>> Hm, what standard exactly do you refer too.
> 
> standard, adjective [1622]
> 
>2) (a) regularly and widely used, available, or supplied automobile equipment> (b) well-established and very familiar standard opera>

widely used and well established in Debian is definitely not the case.

> 
> is what I meant.  /var/run on tmpfs has been common on UNIX platforms for
> many years.  It was standard on Solaris at least as far back as Solaris 8,
> for example.

Afaik, Ubuntu is the only Linux distro which supports and uses tmpfs by default.

I believe you, when you say that it is common on older UNIX platforms or
Solaris, as I don't have experience with them.

Again, if there would be a list of cons, I'd be much happier in supporting this
new policy. Unfortunately I only see disadvantages.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Michael Biebl  writes:
> Russ Allbery wrote:
>> Michael Biebl  writes:

>>> Another class of services which might be affected, are
>>> daemons/programs started by inetd.

>> Why would they put anything in /var/run?

> I guess for the same reasons why other system daemons put stuff in /var/run

They put their PIDs in /var/run so that they can be easily stopped or
checked for status.

So why would something started by inetd put anyting in /var/run?

I'm still having a hard time understanding what's putting files in
/var/run that isn't a daemon.  Even UNIX domain sockets exist generally to
contact a running daemon.  Could you explain what policykit uses /var/run
for, and educate me a bit on why D-Bus services have to put things in
/var/run but don't have init scripts?

-- 
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: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Russ Allbery wrote:
> Michael Biebl  writes:
>> Russ Allbery wrote:
>>> Michael Biebl  writes:
> 
 Another class of services which might be affected, are
 daemons/programs started by inetd.
> 
>>> Why would they put anything in /var/run?
> 
>> I guess for the same reasons why other system daemons put stuff in /var/run
> 
> They put their PIDs in /var/run so that they can be easily stopped or
> checked for status.
> 
> So why would something started by inetd put anyting in /var/run?
> 
> I'm still having a hard time understanding what's putting files in
> /var/run that isn't a daemon.  Even UNIX domain sockets exist generally to

Why is a system service that is started by inetd or D-Bus not a daemon?
Remember the times when exim4 or samba could still be started via inetd
(although those no longer support inetd mode afaik).
There are still daemons though (like proftpd comes to mind), which ship a
subdirectory in /var/run and support inetd.


> contact a running daemon.  Could you explain what policykit uses /var/run
> for, and educate me a bit on why D-Bus services have to put things in
> /var/run but don't have init scripts?

PolicyKit stores credentials in /var/run/PolicyKit which are of temporary nature
and are automatically cleaned up on boot.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Michael Biebl  writes:

> Why is a system service that is started by inetd or D-Bus not a daemon?
> Remember the times when exim4 or samba could still be started via inetd
> (although those no longer support inetd mode afaik).

Why would you store your PID somewhere if you're started from inetd
(that's the main thing daemons use it for)?  There's nothing to manage;
when you're running in inetd mode, you process one connection and exit.
There's no purpose served by storing the PID anywhere (and indeed since
multiple copies can be running at the same time, it's not clear how you
would even do such a thing).

> There are still daemons though (like proftpd comes to mind), which ship a
> subdirectory in /var/run and support inetd.

What does it use the directory for?

> PolicyKit stores credentials in /var/run/PolicyKit which are of
> temporary nature and are automatically cleaned up on boot.

Oh, okay, so you're similar to sudo where you're taking advantage of the
fact that /var/run is cleaned on boot but isn't world-writable.

sudo appears to create its directory dynamically if it doesn't already
exist.  I assume the reason why you can't take that approach is that
PolicyKit doesn't run as root and hence can't create directories in
/var/run?

I believe the original motivation for tmpfs /var/run in Solaris was that
it was pointless to maintain scripts that try to clean /var/run (or /tmp
or any other defined-transient directory) on boot, which can be dangerous
and tricky if you don't write them carefully, when you can just put them
in tmpfs and have the cleaning happen automatically without doing any
work.  It simplifies the boot process and eliminates a whole class of
potential directory traversal races that you otherwise have to think
about.  Potential additional boot speed from writing all the startup PID
files to a tmpfs file system (and benefits for flash drives as the only
system storage and similar special configurations) are just a bonus.

-- 
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: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Michael Biebl]

Russ Allbery schrieb:
> 
> I believe the original motivation for tmpfs /var/run in Solaris was that
> it was pointless to maintain scripts that try to clean /var/run (or /tmp
> or any other defined-transient directory) on boot, which can be dangerous
> and tricky if you don't write them carefully, when you can just put them

But this functionality is already there as Debian supports a static
/var/run and support for that is not going away. Maybe Petter can
comment if this ever posed any (security) problems.

> in tmpfs and have the cleaning happen automatically without doing any
> work.  It simplifies the boot process and eliminates a whole class of

I'm not sure I get that point. Why is the boot process simplified if now
every script has to check for it's run directory and potentially create
it or having to introduce fake boot scripts, which do nothing but create
a run directory.

> potential directory traversal races that you otherwise have to think
> about.  Potential additional boot speed from writing all the startup PID
> files to a tmpfs file system (and benefits for flash drives as the only
> system storage and similar special configurations) are just a bonus.

I doubt, that the boot process will be faster if I have to fork a shell
and create a run directory. And the /var/run directory is not something
that is constantly written at, so I also doubt that it will buy you much
of your flash drive life.

But let's be pragmatic, if we want to support both methods,  why should
we have to touch dozens (if not hundreds) of init script if I can do the
same with 10 lines of shell code (which does the backup/restore) and
this problem is solved today. I don't think this solution is less
elegant then fixing a myriad of init scripts.

I'm even willing to write such a patch and post it here for review.

Cheers,
Michael

P.S: That's it from my side for a while. I'll be waiting for comments
from other DDs first.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Raphael Geissert]

Michael Biebl wrote:

> Russ Allbery schrieb:
[...]
> 
>> in tmpfs and have the cleaning happen automatically without doing any
>> work.  It simplifies the boot process and eliminates a whole class of
> 
> I'm not sure I get that point. Why is the boot process simplified if now
> every script has to check for it's run directory and potentially create
> it or having to introduce fake boot scripts, which do nothing but create
> a run directory.

Why do you need fake boot scripts? I haven't seen you prove a fair use of
those.
It also appears that some are unused; I have the daemon running on my system
but there's an empty dir in /var/run without anything in there.

> 
>> potential directory traversal races that you otherwise have to think
>> about.  Potential additional boot speed from writing all the startup PID
>> files to a tmpfs file system (and benefits for flash drives as the only
>> system storage and similar special configurations) are just a bonus.
> 
> I doubt, that the boot process will be faster if I have to fork a shell
> and create a run directory. And the /var/run directory is not something
> that is constantly written at, so I also doubt that it will buy you much
> of your flash drive life.

All those system calls (except forking the shell, which by the way should
already be in cache so no read from disk) cause no write operation on the
disk, which saves time, energy, and sector writes in SSDs.

> 
> But let's be pragmatic, if we want to support both methods,  why should
> we have to touch dozens (if not hundreds) of init script if I can do the

hundreds? I think you are exaggerating, why don't you provide real numbers?

> same with 10 lines of shell code (which does the backup/restore) and
> this problem is solved today. I don't think this solution is less
> elegant then fixing a myriad of init scripts.
> 

As Russ already said, the FHS requires that all files in /var/run be deleted
on reboot; so there's a "myriad" of bogus init scripts.

Cheers,
Raphael Geissert



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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Russ Allbery]

Raphael Geissert  writes:

> As Russ already said, the FHS requires that all files in /var/run be
> deleted on reboot; so there's a "myriad" of bogus init scripts.

Well, to be fair, it requires that all *files* be deleted, not
directories.  It doesn't really say anything clear about directories other
than recommending that they be used if an application has more than one
file.

-- 
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: Improvements to ‘debian/watch’ for fetching from VCS

[Ben Finney]

Raphael Geissert  writes:

> Ben Finney wrote:
> > * the fact that the URL doesn't necessarily indicate what VCS tool is
> >   needed to interact with it (just about all of them allow an HTTP URL
> >   for public read-only access, so that's what will commonly be used
> >   here)
> 
> That can easily solved, svn+http://...

I'd prefer, if the information is to be encoded in the URL, that the
URL should remain useable as-is with the VCS tool itself.

I know that's possible for ‘svn+http://’, but it's not possible for
‘bzr+http://’ if the files are merely stored on plain HTTP (i.e.
without a Bazaar server driving it). What about others?

> > * the plethora of different concepts for mapping identifiers to
> >   specific working trees in different VCSen (revision-id and branches
> >   and tags, oh my!)
> 
> uscan would retrieve the information (say the output of svn info
> svn://domain.tld/repo/) and match the rest of the pattern against the
> output. Whataver is specified is what would uscan would svn export.

No, I'm referring to the fact that one wants to specify not just the
repository location, but all the information necessary to identify a
specific working tree state from the repository. Which might be a
particular revision committed, or a branch or a tag or whatever. Those
have different syntax, and different semantics, in the different
VCSes, IIUC.

-- 
 \ “We demand rigidly defined areas of doubt and uncertainty!” |
  `\—Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas |
_o__)Adams |
Ben Finney


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

Re: Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

[Daniel Burrows]

On Wed, Apr 01, 2009 at 06:54:22PM +0200, "Milan P. Stanic"  
was heard to say:
> On Wed, 2009-04-01 at 09:09, Mike Bird wrote:
> > On Wed April 1 2009 00:03:10 Sune Vuorela wrote:
> > > Qoreutils is a reimplementation of the classic tools from coreutils,
> > > such as ls, mkdir and cp
> > Thanks but this won't be necessary.  We just uploaded a GCC patch
> > that converts coreutils to use Qt.  No source changes are needed.
> 
> Sorry for my ignorance, but what does that mean? We will have to install
> libqt always?

  It means you need to read the Date: header. :-)

  Daniel


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

Re: Improvements to ‘debian/watch’ for fetching from VCS

[Raphael Geissert]

Ben Finney wrote:

> Raphael Geissert  writes:
> 
>> Ben Finney wrote:
>> > * the fact that the URL doesn't necessarily indicate what VCS tool is
>> >   needed to interact with it (just about all of them allow an HTTP URL
>> >   for public read-only access, so that's what will commonly be used
>> >   here)
>> 
>> That can easily solved, svn+http://...
> 
> I'd prefer, if the information is to be encoded in the URL, that the
> URL should remain useable as-is with the VCS tool itself.
> 
> I know that's possible for ‘svn+http://’, but it's not possible for
> ‘bzr+http://’ if the files are merely stored on plain HTTP (i.e.
> without a Bazaar server driving it). What about others?

How does bzr recognise whether it should use http or not?
uscan would of course hand over that part of the job to the $VCS tool, it
would be painful to implement every single vcs protocol out there.

> 
>> > * the plethora of different concepts for mapping identifiers to
>> >   specific working trees in different VCSen (revision-id and branches
>> >   and tags, oh my!)
>> 
>> uscan would retrieve the information (say the output of svn info
>> svn://domain.tld/repo/) and match the rest of the pattern against the
>> output. Whataver is specified is what would uscan would svn export.
> 
> No, I'm referring to the fact that one wants to specify not just the
> repository location, but all the information necessary to identify a
> specific working tree state from the repository. Which might be a
> particular revision committed, or a branch or a tag or whatever.

Could you please give some detailed/real life examples?
Remember that uscan looks for latest upstream versions, it may not
necessarily find a version that has been packaged.

> Those 
> have different syntax, and different semantics, in the different
> VCSes, IIUC.
> 

Sure, but support for each vcs would be independent from each other and may
not all be added, at the same time or ever.

Cheers,
Raphael Geissert



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

Re: Improvements to ‘debian/watch’ for fetching from VCS

[Ben Finney]

Raphael Geissert  writes:

> Ben Finney wrote:
> 
> > I'd prefer, if the information is to be encoded in the URL, that
> > the URL should remain useable as-is with the VCS tool itself.
> > 
> > I know that's possible for ‘svn+http://’, but it's not possible
> > for ‘bzr+http://’ if the files are merely stored on plain HTTP
> > (i.e. without a Bazaar server driving it). What about others?
> 
> How does bzr recognise whether it should use http or not?

I don't understand the question. I'll try to answer what might be the
question; if this doesn't answer you, please re-phrase.

Bazaar can use HTTP as a transport for file-level operations; that's
what a ‘http://’ URL specifies. The server doesn't need to be anything
except a static HTTP server.

Bazaar can alternatively use HTTP as a transport for Bazaar “smart
server” commands, requiring a Bazaar server to be answering at the
other end. That's what a ‘bzr+http://’ URL specifies.

> uscan would of course hand over that part of the job to the $VCS
> tool, it would be painful to implement every single vcs protocol out
> there.

My point is that a URL of the form ‘http://’ would be common, for
repositories that are available publicly only via file-level HTTP, but
uscan would not know from the URL which VCS tool to use.

In other words, encoding the information about which VCS tool to use
is incompatible with my request to preserve the URL for use as-is
outside ‘uscan’.

> Could you please give some detailed/real life examples? Remember
> that uscan looks for latest upstream versions, it may not
> necessarily find a version that has been packaged.

That's exactly what I began talking about: I want uscan to gain the
capability to retrieve a specific, identified working tree state from
the VCS repository.

-- 
 \   “Instead of having ‘answers’ on a math test, they should just |
  `\   call them ‘impressions’, and if you got a different |
_o__)   ‘impression’, so what, can't we all be brothers?” —Jack Handey |
Ben Finney


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Paul Wise]

On Sat, Apr 4, 2009 at 7:37 AM, Michael Biebl  wrote:

> Afaik, Ubuntu is the only Linux distro which supports and uses tmpfs by 
> default.

The OpenEmbedded distros do this too, I've especially seen that the
ones associated with OpenMoko do that.

In addition the pkg-fso folk's Debian for OpenMoko installer script
puts /var/run, /var/lock on a tmpfs and presumably when d-i supports
the OpenMoko devices that will be the default on such devices.

> Again, if there would be a list of cons, I'd be much happier in supporting 
> this
> new policy. Unfortunately I only see disadvantages.

I guess you mean pros rather than cons. One would be that it reduces
the number of useless writes to disk/flash, which could be important
for mobile situations like phones.

-- 
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: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Steve Langasek]

On Sat, Apr 04, 2009 at 01:14:51AM +0200, Michael Biebl wrote:
> > Ubuntu.  The FHS is silent about directories in /var/run across reboots
> > but requires that all files in /var/run be deleted on reboot.

> >> 4.) You have to manually cleanup in postrm. (I guess most packages will 
> >> forget
> >> that, leaving cruft around)

> > If you're creating any files in /var/run during the operation of the
> > package (and if not, why do you have a directory in /var/run in the first
> > place?), then you have to do this anyway, so this isn't new.  (Well, I
> > suppose you could just rely on the next reboot deleting them, but that
> > doesn't feel very clean and I'm not sure that's really in the spirit of
> > our requirements.)

> Not really. Say you have a pretty standard system daemon
> When the daemon is stopped in postinst, the pid file will be automatically
> deleted and dpkg will cleanup the remaining /var/run/$foo directory.

I think he's referring to the fact that the FHS requires all files in
/var/run to be cleared on boot.  We have an init script
(/etc/rcS.d/S36mountall-bootclean) that takes care of this at the system
level, though, on behalf of all packages; the trouble is it's a lot less
efficient, overall, to have to repeatedly clean /var/run on boot than it is
to just write it to a tmpfs and let the contents be lost on reboot.

> >> 5.) If your package does not have an init script (I happen to maintain
> >> two such packages), I now have to create init scripts simply to create a
> >> /var/run directory. That's insane and even more wasting cpu cycles.

> > Could you provide more details about what package without an init script
> > uses /var/run?  The only other case that I can think of is packages that
> > create transient UNIX-domain sockets.

> policykit is such an example. Potentially as D-Bus system bus activated system
> services are affected by this, because they (usually) don't ship any init 
> script.

$ grep -A4 'start)' /etc/init.d/policykit 
  start)
mkdir -p /var/run/PolicyKit
chown root:polkituser /var/run/PolicyKit
chmod 770 /var/run/PolicyKit
;;
$

That's what I have on an Ubuntu system; why can't the Debian package do the
same?

(Yes, this is the only function of this init script.  But still, either you
create the directories on boot or you have to clean all the files on boot.)

> We will se such services more and more in the future (like it or not).

No.  Services that work that way are Doing It Wrong, and we should not
accept this as inevitable.

> I provided a list of cons of tmpfs (you could probably also add, that it
> breaks selinux). Is there actually a list of pros?

"Probably"?  In what case does this break selinux?

> > Personally, I'm not inclined to revert this change.  I think it's correct
> > and continues to be correct, and I'd rather not undo the work that's
> > already been put into making it work.  This was added to Policy in part
> > because of various bug reports against packages not working as expected,
> > so removing it from Policy won't make those bug reports go away again.
> > And I think it's better to fix the packages than to add something to
> > preserve /var/run directories across boot, which seems like a hack to me.

> Not more of a hack than adding init scripts which do nothing else then 
> creating
> /var/run/foo, with the added benefit that only the users (minority) which
> actually use RAMRUN would have to live with this "hack".

I would like to see /var/run become the default on Debian as well,
eventually...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Bug#522454: ITP: protobuf -- Protocol Buffers are a way of encoding structured data in an efficient yet extensible format.

[Iustin Pop]

On Fri, Apr 03, 2009 at 11:25:22PM +0200, Sune Vuorela wrote:
> On Friday 03 April 2009 23:02:28 Ehren Kret wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Ehren Kret 
> >
> >
> > * Package name: protobuf
> >   Version : 2.0.3
> >   Upstream Author : Kenton Varda , et al.
> > * URL : http://code.google.com/p/protobuf/
> 
> http://packages.qa.debian.org/p/protobuf.html  ?
> 
> Though it looks like it could kind of need a hand.

The maintainer (i.e.) is just a little (or more) swamped with other stuff and
was waiting for the new python policy changes to settle down before packaging
the new upstream version.

thanks,
iustin


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

Re: Why do we have to support tmpfs for /var/run (policy changes in 3.8.1)

[Petter Reinholdtsen]

[Michael Biebl]
>> I believe the original motivation for tmpfs /var/run in Solaris was
>> that it was pointless to maintain scripts that try to clean
>> /var/run (or /tmp or any other defined-transient directory) on
>> boot, which can be dangerous and tricky if you don't write them
>> carefully, when you can just put them
> 
> But this functionality is already there as Debian supports a static
> /var/run and support for that is not going away. Maybe Petter can
> comment if this ever posed any (security) problems.

Not quite sure what the question is.  As far as I know, Debian
supported tmpfs mounted /var/run when I become co-maintainer of
sysvinit, and I have tried to keep it this way.  The only recent
changes it that it has become easier to enable it.  Very good to
notice that this now is documented in the policy.

If you wonder what the advantages of tmpfs in /var/run is, I know of
several, but do not really have time to track down them all.  One of
them I care specially about is the fact that it allow a computer to
boot with a read-only local file system (think diskless workstations
and thin clients booting LTSP, machines with flash disks and files
with problems with their file systems), and I believe this is a clear
advantage.  Having tmpfs there also make it more obvious that the
content of /var/run/ will be erased at boot.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Improvements to ‘debian/watch’ for fetching from VCS (was: This topic died off; any resolution?)

[Andreas Tille]

On Fri, 3 Apr 2009, Raphael Geissert wrote:


One additional thought: We store packaging Vcs and upstream homepage
in debian/control.  What about storing upstream Vcs there as well and
teach uscan to look there as well.  Just a rough thought.


And do what with it? how will it know what it should look for? that's why
all that information is in and belongs to the watch files.


Why not teaching uscan reading uscan watch *and* control file.  IMHO
the upstream VCS might be useful for other tools than uscan as well
and duplicating information is bad.

Kind regards

  Andreas.

--
http://fam-tille.de


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