date:20090910

Re: RFC: Providing vi when /usr isn't mounted

2009-09-10 Thread Miquel van Smoorenburg

On Wed, 2009-09-09 at 19:02 -0400, James Vega wrote:
> tag 528494 help
> thanks
> 
> #528494 raised the idea of having vim-tiny (the default vi-like editor
> on a base install) provide /bin/vi so that it would be accessible in
> situations where /usr isn't available.  At first glance, I naïvely
> figured this would be an easy change.  Of course, this wasn't the case
> so I'd like to get some feedback on the proper approach for this since
> this use case is actually something I've intended on doing since
> vim-tiny became Priority: important.
> 
> We currently have 8 source packages[0] building binary packages which
> provide vi in some form.  All except elvis-tiny use the alternatives
> system to provide /usr/bin/vi.  Elvis-tiny ships /bin/vi which is a
> small binary implementing its own sort of alternatives functionality[1].
> 
> The problem here is that I can't simply have vim-tiny ship /bin/vi
> partly due to elvis-tiny but primarily due to the alternatives system
> rightly not supporting a provided alternative changing location
> depending on which of the available alternatives is active.

[I sent this as a reply to bug #528494, but forgot to add Cc's, so
 here it is again]

Well, the original bug submission #528494 talks about that- you
cannot have different 'vi' binaries in /bin and /usr/bin, since
that would be very inconsistent.

What /bin/vi in elvis-tiny does is very simple:

- if /usr/bin/vi exists, execute it (common case)
- else if /bin/elvis-tiny exists execute it (/usr not available)
- else print error and exit

This way you always get /usr/bin/vi, even if /bin is in your
PATH first, unless /usr/bin/vi doesn't exist.

We could work together to allow multiple '*vi-tiny' packages to
be installed, in that case we should really do the following:

- each *vi-tiny package sets an alternative for /bin/vi-tiny
- each *vi-tiny package depends on vi-tiny-common
- vi-tiny-common is basically the /bin/vi from elvis-tiny,
  as described above, where it tries to execute /bin/vi-tiny
  instead of /bin/elvis-tiny

However, to me this sounds as a lot of work for very little
gain. We already have the elvis-tiny package to provide a small
vi clone for situations where /usr is not available. This
would be a rescue situation. Is it really neccesary to be
able to choose between tons of vi-clones in that case ?

Mike.


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

Bug#545949: who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?

2009-09-10 Thread Holger Levsen

package: sysv-rc
severity: important
x-debbugs-cc: debian-devel@lists.debian.org
User: debian...@lists.debian.org
Usertags: piuparts piuparts.d.o

Hi Petter,

On Mittwoch, 9. September 2009, Petter Reinholdtsen wrote:
> > today I noticed that quite many packages fail the piuparts test,
> > because of a file left after purge in /var/lib/update-rd.d - who's
> > responsibility is it to clean this up? Each package? Or? Or
> > shouldn't those be cleaned on purge and piuparts should ignore those
> > files? (I don't think the latter is the correct approach.)
>
> The directory belong to the sysv-rc package, and will be cleaned up
> when that package is removed. :)
>
> We discussed on IRC to remove files from there when update-rc.d is
> asked to remove symlinks to a script, and if we decide to implement it
> that would solve the piuparts issue.  Thanks for bringing it to our
> attention. :)

Thanks for your reply, filing a bug so this doesnt get forgotten.


regards,
Holger


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

Re: Modifying /etc/nsswitch.conf in Debian Packages

2009-09-10 Thread Jonas Smedegaard


Hi Luke,

On Wed, Sep 09, 2009 at 09:58:34PM -0400, Luke Faraone wrote:
I'm currently working on packaging 
Rainbow, an implementation of the 
Bitfrost  security 
spesification. Rainbow runs user-level desktop applications with the 
same level of resource isolation already used with a variety of system 
daemons, giving each application instance its own UID, GID, and 
persistent storage directory.


In order to function, Rainbow requires a NSS module, libnss-rainbow, to 
be installed and enabled in /etc/nsswitch.conf.


From what I can tell (as seen on bug 
388864 ), 
libnss-mdns modifies /etc/nsswitch.conf directly as part of its 
postinst. I thought this wasn't allowed by Debian policy, but if I'm 
misunderstanding I'm more than happy to adopt their solution.


libnss-mdns 0.10-3.1 currently in Sid contains the following:

 README.Debian 
Previously the base-files package shipped /etc/nsswitch.conf and specified:

hosts:  files dns mdns

However, due to bug#351990, this is no longer the case. /etc/nsswitch.conf
is now generated post-installation. Upon installation of nss-mdns, if the
strings 'mdns', 'mdns_minimal', 'mdns4', 'mdns4_minimal', 'mdns6' or
'mdns6_minimal' appear on the hosts line, your /etc/nsswitch.conf file
will not be updated, otherwise it will updated to match the upstream
recommended configuration which usually looks like:

hosts:  files mdns4_minimal [NOTFOUND=return] dns mdns4
 README.Debian 

Perhaps you could do similar arrangements until a unified solution is 
found.



On Ubuntu AuthClientConfig  
seems to serve a similar purpose. Assuming the above workaround was not 
acceptable, would porting ACC to Debian and using that hook in my 
package be so?


I don't know that tool (and have no time to investigate it currently) so 
can't comment on that at the moment.




Please CC me, as I'm not subscribed to this list.


You _are_ subscribed to the OLPC list at Alioth, so I've just made sure 
to include that one :-)



Regards,

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Faster boot by running init.d scripts in parallel

2009-09-10 Thread Petter Reinholdtsen

One "hidden" feature of the current Debian boot sustem, is the ability
to run the init.d scripts in parallel. This require dependency based
boot sequencing to be enabled, and the init.d script dependencies to
be complete and correct to work reliably. The feature is hidden and
undocumented, because we plan to drop the CONCURRENCY variable in the
future and make concurrent booting the default when dependency based
boot sequencing is enabled.

If you want to test this feature in testing or unstable, use this
command:

echo CONCURRENCY=makefile >> /etc/default/rcS

It will enable makefile style concurrency, and run N scripts in
parallel during boot, where N is the number of CPUs or cores on the
machine. This only work when dependency based boot sequencing. This
can be enabled using

dpkg-reconfigure insserv sysv-rc

If some services fail to work properly, the problem is most likely
because of bugs in the init.d script headers. See
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > for
clues on how to fix it. Most scripts have correct enough dependency
information, but help is needed to find and fix the remaning few with
bugs. Please make sure to usertag reported bugs to make them show up
on
http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=initscripts-ng-de...@lists.alioth.debian.org
>

If you want to improve boot speed even more, I recommend installing
the readahead-fedora packages, and boot once with the 'profile' kernel
option to adjust its readahead list to the list of files needed during
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

Explicitely Cc bug reporters

2009-09-10 Thread Samuel Thibault

Hello,

I'd like to remind maintainers that in order to reach bug reporters to
ask for tests etc. you _need_ to explicitely Cc the bug reporter, else
he won't receive the mail and of course not do the tests etc.  It's now
quite a few times that I have received a "you didn't answer" mail...

Samuel


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

59 matches

Mail list logo