Bug#609097: RFP: scannedonly -- scalable samba anti-virus module

[Falk Hackenberger]

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

--- Please fill out the fields below. ---

   Package name: scannedonly
Version: 0.21
Upstream Author: Olivier sessink o...@users.sourceforge.net]
URL: http://olivier.sessink.nl/scannedonly
License: GPL version 2
Description: Scannedonly is a samba VFS module and a scanning daemon
that ensure that only files that have been scanned for viruses are
visible and accessible to the end user.

Scannedonly was developed because of scalability problems with
samba-vscan: high server loads when (the same) files were requested
often, and timeouts when large zip files were requested. Scannedonly
doesn't have these problems, but it does introduce some other issues.
Choose the product that suits you best.

As samba since samba-3.5.0 have always incleded the VFS modul you need
only daemon. The default daemon uses clamav.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d2581eb.5060...@spam.huckley.de

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Thu, Jan 6, 2011 at 1:54 AM, Ted Ts'o  wrote:
>> I was thinking, doesn't ext have this kind of dependency tracking already?
>> It has to write the inode after writing the data, otherwise the inode
>> might point to garbage.
>
> No, it doesn't.  We use journaling, and forced data writeouts, to
> ensure consistency.

Suppose I append one byte to an existing file, I don't use fsync.
Will it commit the inode with the increased size before the data byte
is written?
In that case, garbage might show up in my file.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=dw8ks+s3ynw+1-axk3-tsx0ez5g+or5cgv...@mail.gmail.com

Re: Safe File Update (atomic)

[Bernhard R. Link]

* Ted Ts'o  [110105 19:26]:
> So one of the questions is how much should be penalizing programs that
> are doing things right (i.e., using fsync), versus programs which are
> doing things wrong (i.e., using rename and trusting to luck).

Please do not call it "wrong". All those programs doing is not
requesting some specific protection. They are doing file system
operations that are totally within the normal abstraction level of
file system interfaces. While some programs might be expected to
anticipicate cases not within that interface (i.e. the case that
due to some external event the filesystem is interupted in what it
does and cannot complete its work), that is definitly not the
responsibility of the average program, especially if there is no
interface for this specific problem (i.e. requesting a barrier to only
do a rename after the new file is actually commited to disk).

So the question is: How much should the filesystem protect my data in
case of sudden power loss? Should it only protect data where the program
explicitly requested something explicitly, or should it also do what
it reasonably can to protect all data.

Having some performance knobs so users can choose between performance
and data safety is good. This way users can make decisions depending
what they want.

But a filesystem losing data so easily or with a default setting losing
data so easily is definitly not something to give unsuspecting users.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110106105913.gb14...@pcpool00.mathematik.uni-freiburg.de

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Thu, Jan 6, 2011 at 5:01 AM, Ted Ts'o  wrote:
> On Thu, Jan 06, 2011 at 12:57:07AM +, Ian Jackson wrote:
>> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
>> > Then I invite you to implement it, and start discovering all of the
>> > corner cases for yourself.  :-)  As I predicted, you're not going to
>> > believe me when I tell you it's too hard.
>>
>> How about you reimplement all of Unix userland, first, so that it
>> doesn't have what you apparently think is a bug!
>
> I think you are forgetting the open source way, which is you scratch
> your own itch.

Most of the time one is writing software because it's useful for
oneselves and others. Not because writing software itself is so much
fun. It's about the result.
So focus should be on what those users need/want.

> The the main programs I use where I'd care about this (e.g., emacs)
> got this right two decades ago; I even remember being around during
> the MIT Project Athena days, almost 25 years ago, when we needed to
> add error checking to the fsync() call because Transarc's AFS didn't
> actually try to send the file you were saving to the file server until
> the fsync() or the close() call, and so if you got an over-quota
> error, it was reflected back at fsync() time, and not at the write()
> system call which was what emacs had been expecting and checking.
> (All of which is POSIX compliant, so the bug was clearly with emacs;
> it was fixed, and we moved on.)

Would you classify the emacs implementation of safe file write
semantics simple or complex?
Why did they not get it right the first time?
IMO it's because the API is hard to use and easy to misuse, while it
should be the other way around.
Hiding behind POSIX semantics is easy but doesn't solve the problem.

> Note that all of the modern file systems (and all of the historical
> ones too, with the exception of ext3) have always had the same
> property.  If you care about the data, you use fsync().  If you don't,
> then you can take advantage of the fact that compiles are really,
> really fast.  (After all, in the very unlikely case that you crash,
> you can always rebuild, and why should you optimize for an unlikely
> case?  And if you have crappy proprietary drivers that cause you to
> crash all the time, then maybe you should rethink using said
> proprietary drivers.)
>
> That's the open source way --- you scratch your own itch.  I'm
> perfectly satisifed with the open source tools that I use.  Unless you
> think the programmers two decades ago were smarter, and people have
> gotten dumber since then (Are we not men?  We are Devo!), it really
> isn't that hard to follow the rules.

I think the number of programmers today is much larger than it was two
decades ago and I also think the average experience of the programmer
went down.

Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikj-yl_emcavvls_xn3imrqcpzteavqpey...@mail.gmail.com

Re: Safe File Update (atomic)

[Bastien ROUCARIES]

On Thu, Jan 6, 2011 at 12:39 PM, Olaf van der Spek  wrote:
> On Thu, Jan 6, 2011 at 5:01 AM, Ted Ts'o  wrote:
>> On Thu, Jan 06, 2011 at 12:57:07AM +, Ian Jackson wrote:
>>> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
>>> > Then I invite you to implement it, and start discovering all of the
>>> > corner cases for yourself.  :-)  As I predicted, you're not going to
>>> > believe me when I tell you it's too hard.
>>>
>>> How about you reimplement all of Unix userland, first, so that it
>>> doesn't have what you apparently think is a bug!
>>
>> I think you are forgetting the open source way, which is you scratch
>> your own itch.
>
> Most of the time one is writing software because it's useful for
> oneselves and others. Not because writing software itself is so much
> fun. It's about the result.
> So focus should be on what those users need/want.
>
>> The the main programs I use where I'd care about this (e.g., emacs)
>> got this right two decades ago; I even remember being around during
>> the MIT Project Athena days, almost 25 years ago, when we needed to
>> add error checking to the fsync() call because Transarc's AFS didn't
>> actually try to send the file you were saving to the file server until
>> the fsync() or the close() call, and so if you got an over-quota
>> error, it was reflected back at fsync() time, and not at the write()
>> system call which was what emacs had been expecting and checking.
>> (All of which is POSIX compliant, so the bug was clearly with emacs;
>> it was fixed, and we moved on.)

Could you point to the code snippet ? I could be worth to add to
gnulib for instance

Another point is to create some fuse filesytem for testing error
condition on filesystem. For instance a filesystem that create EIO
error randomly or EFULL, it will improve the quality of our software.
I have written such a filesystem, I will surelly post it in a few day
(hopefully)

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktin5v_cuuetf3j1p1_mtkv3oq2+sk9vstn453...@mail.gmail.com

squeeze will not have googleearth-package

[Holger Levsen]

Hi,

so googleearth-package was removed from squeeze, because of a RC bug, which 
was fixed on mentors.d.n for 4 days already when it was removed. Sadly the 
maintainer didnt ask for sponsorship on the mentors-list, so his uploaded was 
not noticed immediatly.

Then, 605959 asking for its removal was filed (against r.d.o, without 
notifiying the g-p mainatiner) and the packages was removed within 7 hours.

That same day I sponsored the package, sadly that upload introduced 606045, 
which we fixed on the next day.

That was a month ago. 

Since then I was hoping that some nice releaseteam member would it go in 
again, after it all it wont even be part of squeeze, it's just in contrib. 
And it has millions of users there, whether you like it or not. (I dont, but 
I have to cater for quite some users who love it.)

So I'm closing 606222 now, to not have to think about it anymore. 

At least we have the elephant in the room, gladly to help our users.


cheers,
Holger


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

Bug#609121: ITP: nflog-bindings -- High-level bindings for libnetfilter_log

[Pierre Chifflier]

Package: wnpp
Severity: wishlist
Owner: Pierre Chifflier 

* Package name: nflog-bindings
  Version : 0.1
  Upstream Author : Pierre Chifflier 
* URL : 
https://www.wzdftpd.net/redmine/projects/nflog-bindings/wiki/
* License : GPLv3
  Programming Lang: C, Python, Perl
  Description : High-level bindings for libnetfilter_log

 nflog-bindings is a set of high-level modules for several languages
 (Python and Perl, for the moment), for libnetfilter_log.
 It provides a userspace API to access packets that have been queued by
 the kernel packet filter using the NFLOG target.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110106102208.12282.86853.report...@piche2.inl.fr

Directories named after packages

[Ian Jackson]

Many of the bits of the policy manual, and informal practice, suggest
naming directories after your package.

I just wanted to make a point that perhaps hasn't been entirely clear:
when we say that you should name the directory after your package, you
should think carefully about what aspect of and/or subsection of the
package name to use.

If the directory is some piece of package innards which nothing
outside the package itself needs to care about and which the user
never sees, then probably the actual package name is a good choice -
that way if the package is renamed or forked in the future, it will be
able to coexist with its differently-named predecessors.

BUT if the directory is user-visible, or is going to be used by other
packages, or needs to be configured in the user's PATH, or something,
then it will often be better to pick the "stem" of the package name,
or something else more stable.  

Also, if the package is renamed, then normally the existing config
directory name, plugin directories, or whatever, should be retained
unless there are good reasons not to.  To change the directory name
along with the package name may provide a minor benefit in neatness,
but it causes a lot of transition aggro (for other maintainers, and of
course for users/admins).

In general, the principle should be that where to look in the
filesystem for something should not depend on how the packages have
been organised.

For example, there has been a recent trend for FOO's documentation
package FOO-doc to contain /usr/share/doc/FOO-doc/html/index.html (or
whatever).  I think this is daft.  It should be in
/usr/share/doc/FOO/html/index.html.  That way you can find the
documentation for FOO in the filesystem without knowing whether the
FOO package happens to have been split into FOO and FOO-doc, or for
that matter libFOO8.9-dev, FOO-bin, etc. etc. etc.

Ian.

A footnote: I was in part prompted to write this email by
/usr/lib/git-core, the directory that some git .debs expect you to put
on your PATH if you prefer to have "git-WOMBAT" commands rather than
just "git WOMBAT".

But since git upstream think this directory should be called
$(libexec)/git-core, it's very probably right to keep that name in
Debian.  So that's not a good example after all.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19749.55214.255224.395...@chiark.greenend.org.uk

Re: Directories named after packages

[Osamu Aoki]

Hi,

On Thu, Jan 06, 2011 at 02:54:38PM +, Ian Jackson wrote:
> Many of the bits of the policy manual, and informal practice, suggest
> naming directories after your package.
> 
...
> In general, the principle should be that where to look in the
> filesystem for something should not depend on how the packages have
> been organised.
> 
> For example, there has been a recent trend for FOO's documentation
> package FOO-doc to contain /usr/share/doc/FOO-doc/html/index.html (or
> whatever).  I think this is daft.  It should be in
> /usr/share/doc/FOO/html/index.html.  That way you can find the
> documentation for FOO in the filesystem without knowing whether the
> FOO package happens to have been split into FOO and FOO-doc, or for
> that matter libFOO8.9-dev, FOO-bin, etc. etc. etc.

As for /usr/share/doc/* area, there are a few types of stems chosen.

1. package name: alsa-base, aptitude, aptitude-doc-en, ... 
   (lower case, most common)
2. Category name: FAQ, HOWTO, HTML, RFC
   (Always upper case)
3. Historic/Upstream choice (?): /usr/share/doc/texmf
   (Several TeX packages uses this.)

I agree that historical best practice for FOO-doc was to put
documentation in /usr/share/doc/FOO or /usr/share/doc/FOO-common (when
there is FOO1 and FOO2 variants but one each of FOO-doc and FOO-common
package).

One of the early days of debian-doc before I joined created doc-base for
package so we can have one single data base to look.  Unfortunately, I
hear some packages do not use it these days but it is very good shape in
general.  /usr/share/doc/HTML is populated with data taken from doc-base
as I understand.  But it is much nice to have documents located by their
package name stem.

In any case, this is about *best practice* and something to put in
developers reference, I think.

If /usr/share/doc/FOO-doc has html, it will be at least nice to have
symlink from /usr/share/doc/FOO.

If we go for this common practice, we may need to ask FAQ, HOWTO, RFC,
texmf to be changed/moved to regular places.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110106164807.ga3...@debian.org

Re: Directories named after packages

[Russ Allbery]

Ian Jackson  writes:

> For example, there has been a recent trend for FOO's documentation
> package FOO-doc to contain /usr/share/doc/FOO-doc/html/index.html (or
> whatever).  I think this is daft.  It should be in
> /usr/share/doc/FOO/html/index.html.  That way you can find the
> documentation for FOO in the filesystem without knowing whether the FOO
> package happens to have been split into FOO and FOO-doc, or for that
> matter libFOO8.9-dev, FOO-bin, etc. etc. etc.

See http://bugs.debian.org/106073 and the discussion there.  Wording
proposals very welcome.

> A footnote: I was in part prompted to write this email by
> /usr/lib/git-core, the directory that some git .debs expect you to put
> on your PATH if you prefer to have "git-WOMBAT" commands rather than
> just "git WOMBAT".

> But since git upstream think this directory should be called
> $(libexec)/git-core, it's very probably right to keep that name in
> Debian.  So that's not a good example after all.

In this case, upstream has deprecated the git-WOMBAT syntax as I
understand it, so you're sort of swimming upstream on that one.

-- 
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
Archive: http://lists.debian.org/87pqs97w6l@windlord.stanford.edu

Re: Directories named after packages

[Ian Jackson]

Russ Allbery writes ("Re: Directories named after packages"):
> Ian Jackson  writes:
> 
> > For example, there has been a recent trend for FOO's documentation
> > package FOO-doc to contain /usr/share/doc/FOO-doc/html/index.html (or
> > whatever).  I think this is daft.  It should be in
> > /usr/share/doc/FOO/html/index.html.  That way you can find the
> > documentation for FOO in the filesystem without knowing whether the FOO
> > package happens to have been split into FOO and FOO-doc, or for that
> > matter libFOO8.9-dev, FOO-bin, etc. etc. etc.
> 
> See http://bugs.debian.org/106073 and the discussion there.  Wording
> proposals very welcome.

OMG it's from 2001 ...

Ben Finney's patch in message 92 from August seems like a very good
start.  

It might be better to actually use the word "administrivia" in the
policy manual, or to use some other wording to make it clear exactly
what should be in the actual package's directory.  Something like

  adminstrivia (ie, files which document the _binary package itself_,
  such the documentation package's copyright file, its (perhaps
  duplicate copy of) changelogs, and so on) should be in the actual
  package's directory

It would also be useful to specify a convention for libfoo*-dev
packages.  Typically for many C libraries we have:
   libfoo1.0} co-
   libfoo2.0}  installable
   libfoo1.0-dev} conflict, contain
   libfoo2.0-dev}   dev docs for each version

Ideally I think the documentation location shouldn't depend on which
version of the dev library you have installed, which suggests one of
   /usr/share/doc/foo
   /usr/share/doc/libfoo
   /usr/share/doc/libfoo-dev

Of course you mayhave:
   libfoo1.0} co-
   libfoo2.0}  installable
   libfoo1.0-dev} conflict, with
   libfoo2.0-dev}   no documentation
   libfoo1.0-doc   } each one contains
   libfoo2.0-doc   }   dev docs for each version

Then is it better to have coinstallable
   /usr/share/doc/foo1.0
   /usr/share/doc/foo2.0
or non-coinstallable
   /usr/share/doc/foo
?

I think policy should probably recommend which of these to use.


> In this case, upstream has deprecated the git-WOMBAT syntax as I
> understand it, so you're sort of swimming upstream on that one.

However they can't stop us (Debian) continuing to provide it :-).
A separate thing you put on your PATH is fine for me.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19750.2113.807584.96...@chiark.greenend.org.uk

Re: Safe File Update (atomic)

[Enrico Weigelt]

> Getting people to believe that you can't square a circle[1] 
> is very hard, 

Just allow an infinite number of steps and it's almost trivial ;-)

> It's like trying teaching a pig to sing. 

Well, that works, just sounds a bit like vogon poetry ;-o

> If you give me a specific approach, I can tell you why it won't work,
> or why it won't be accepted by the kernel maintainers (for example,
> because it involves pouring far too much complexity into the kernel).

To come back to the original question, I'd like to know which concrete
realworld problems should be solved by that. One thing an database-like
transactional filesystem (w/ MVCC) would be nice is package managers: 
we still have the problem that within the update process there may be
inconsistent states (yes, this had already bitten me!) - if it would
be possible to make an update visible atomically, that would be a 
big win for critical 24/7 systems.

My approach to this would be an special unionfs with transactional
semantics (I admit: no idea how complex it would be implementing this)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110106183337.gd14...@nibiru.local

Re: Safe File Update (atomic)

[Olaf van der Spek]

On Thu, Jan 6, 2011 at 7:33 PM, Enrico Weigelt  wrote:
> To come back to the original question, I'd like to know which concrete
> realworld problems should be solved by that. One thing an database-like
> transactional filesystem (w/ MVCC) would be nice is package managers:
> we still have the problem that within the update process there may be
> inconsistent states (yes, this had already bitten me!) - if it would
> be possible to make an update visible atomically, that would be a
> big win for critical 24/7 systems.
>
> My approach to this would be an special unionfs with transactional
> semantics (I admit: no idea how complex it would be implementing this)

A transaction to update multiple files in one atomic go?
Nah, this request is for just a single file, although a future
extension to multiple files shouldn't be too hard.

Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=ur3avv65qfbo+-074fons__8pkq=5zwljm...@mail.gmail.com

Re: Safe File Update (atomic)

[Enrico Weigelt]

* Olaf van der Spek  schrieb:

> A transaction to update multiple files in one atomic go?

Yes. The application first starts an transaction, creates/writes/
removes a bunch of files and then sends a commit. The changes
should become visible atomically and the call returns when the
commit() is completed (and written out to disk). If there're
conflics, the transaction is aborted w/ proper a error code.
So, in case of a package manager, the update will run completely
in one shot (from userland view) or not at all.

I could live with:

a) relatively slow performance (commit taking a second or so)
b) abort as soon as an conflict arises
c) files changed within the transaction are actually new ones
   (sane package managers will have to unlink text files instead
   simply overwriting nevertheless)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110106185922.ge14...@nibiru.local

Re: devel files and libraries in /lib

[Enrico Weigelt]

* Bernhard R. Link  schrieb:

> They do not only include the library in question, but they include many
> other libraries. As paths supplied by the user are searched in before
> anything in the system path, this changes the order the system paths are
> searched in.
> This can both hide a user suplied search path (as it is searched now
> after /usr/lib, so replacing something there does no longer work).

Relying on the search *order* is a really bad idea IMHO. To make it
work, you'll also have to *ensure* the right order on runtime linking.

Why do you want to do that at all ?
Why not simply set up an proper sysroot which just contains exactly
the required libraries ? (and of course, take care that there're no
conflicting library names in the runtime system later).

> And it can change the order in the standard search path
> (so if your linker knows or is told that for the current format it
> needs to look first into some other directory to get the proper libc
> or things like that, the linker will see them too late).

Same as above: solve this issue by using a proper sysroot where
the libc (and other libs) you want to get used are installed, 
and nothing else.

> For example, on a amd64 lenny system run
> gcc -m32 -L/usr/lib hello.c
> 
> and you get:
> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

Multiarch is another bad idea. Use _separate_ toolchains.


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110106190631.gf14...@nibiru.local

Re: devel files and libraries in /lib

[Enrico Weigelt]

* Roger Leigh  schrieb:

> Well, they end up on / to give you /games, /include, /local, /share
> and /src.  Because /usr is a symlink to /, these are still accessible
> as /usr/games, /usr/include etc. for full backward compatibility.

If it's just about getting rid of two (lib|bin|sbin) dirs, why not 
putting everything to /usr/(lib|bin|sbin) and symlink or bind-mount
them to their old location ?


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110106191733.gg14...@nibiru.local

Re: Directories named after packages

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes ("Re: Directories named after packages"):

>> See http://bugs.debian.org/106073 and the discussion there.  Wording
>> proposals very welcome.

> OMG it's from 2001 ...

Yeah, it's almost old enough that I can blame you for the fact that it
wasn't specified that way in the first place.  :)  Not quite, though.

> Ben Finney's patch in message 92 from August seems like a very good
> start.

Agreed.

I'm copying the bug on this message to capture your feedback.

> It might be better to actually use the word "administrivia" in the
> policy manual, or to use some other wording to make it clear exactly
> what should be in the actual package's directory.  Something like

>   adminstrivia (ie, files which document the _binary package itself_,
>   such the documentation package's copyright file, its (perhaps
>   duplicate copy of) changelogs, and so on) should be in the actual
>   package's directory

I'm not sure -- administrivia is one of those words that is immediately
meaningful to me, as a native English speaker, but it's one that sets off
warning bells about whether it would make a lot of sense to someone who
wasn't a native English speaker and isn't that familiar with English
idioms.  Of course, you do immediately then define it.  But I'd be
inclined to just inline that definition in place of the word.

> It would also be useful to specify a convention for libfoo*-dev
> packages.  Typically for many C libraries we have:
>libfoo1.0} co-
>libfoo2.0}  installable
>libfoo1.0-dev} conflict, contain
>libfoo2.0-dev}   dev docs for each version

> Ideally I think the documentation location shouldn't depend on which
> version of the dev library you have installed, which suggests one of
>/usr/share/doc/foo
>/usr/share/doc/libfoo
>/usr/share/doc/libfoo-dev

> Of course you mayhave:
>libfoo1.0} co-
>libfoo2.0}  installable
>libfoo1.0-dev} conflict, with
>libfoo2.0-dev}   no documentation
>libfoo1.0-doc   } each one contains
>libfoo2.0-doc   }   dev docs for each version

> Then is it better to have coinstallable
>/usr/share/doc/foo1.0
>/usr/share/doc/foo2.0
> or non-coinstallable
>/usr/share/doc/foo
> ?

> I think policy should probably recommend which of these to use.

I'm hesitant to recommend moving the documentation to /usr/share/doc/foo
when we've always put it in a directory named after the package in the
past; I'm afraid long-time Debian users won't be able to find it.  I
suppose symlinks would solve that problem.

In my ideal world, as a green-field proposal, I'd like packages:

libfoo1.0-doc
libfoo2.0-doc

to install their documentation into:

/usr/share/doc/libfoo/1.0
/usr/share/doc/libfoo/2.0

I would tend to use libfoo instead of foo unless upstream's name is always
foo.  For most libraries, libfoo is better because foo may be something
else entirely (something that uses the library, for instance).

But that's a big difference from what we have now.

-- 
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
Archive: http://lists.debian.org/874o9l7rzg@windlord.stanford.edu

Bug#609172: ITP: libvendorlib-perl -- Package to enforce only core and vendor perl module usage

[Nicholas Bamber]

Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber 


* Package name: libvendorlib-perl
  Version : 0.05
  Upstream Author : Rafael 
* URL : http://search.cpan.org/dist/vendorlib/
* License : perl
  Programming Lang: perl
  Description : Package to enforce only core and vendor perl module usage

This simply manipulates @INC based upon what is in %Config.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110107015035.11324.56148.report...@leonhartsberger.periapt

Re: Directories named after packages

[Miles Bader]

Russ Allbery  writes:
> I'm hesitant to recommend moving the documentation to /usr/share/doc/foo
> when we've always put it in a directory named after the package in the
> past; I'm afraid long-time Debian users won't be able to find it.

I'd certainly be confused!

Being able to just look in /usr/share/doc/PKG is really, really,
convenient, even if it only contains symlinks/pointers/whatever
referring to the "real" location.

Otherwise looking for related documentation becomes a guessing game
(OK, I guess one can do "dpkg -L pkg | grep /usr/share/doc", but ...).

Thanks,

-miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrmhv58t@catnip.gol.com