On Sep 22, Bdale Garbee [EMAIL PROTECTED] wrote:
Having said that, since I don't personally run bind9 in a chroot, I continue
to be willing to accept a clueful patch to the current bind9 source in non-US
to implement this... but am in no big rush to implement it myself.
There are no packaging
On Sep 24, Christian Kurz [EMAIL PROTECTED] wrote:
So you want to force everyone who is interested in running this chroot
to use a kernel 2.4.x at least? That's in my opinion a not acceptable
Yes, since managing a chroot environment without bind mounts is way
harder and IMO cannot
On Sep 26, Peter Palfrader [EMAIL PROTECTED] wrote:
Are there any problems I missed with cimply copying the files?
Yes: people do not want to restart bind at every configuration changes.
Mount -bind is no option, hardlinks aren't either. Symlinks from
mount --bind is the right solution for
On Sep 27, Steve Greenland [EMAIL PROTECTED] wrote:
(And why does mount(8) document '--bind' but not '-t none' or '-o
bind'?)
Because -o bind is the old API and you are not supposed to use it.
--
ciao,
Marco
On Sep 26, Peter Palfrader [EMAIL PROTECTED] wrote:
AFAIK mount -o ro --bind /etc/ foo/etc does not mount readonly. So
It will in future 2.4 releases.
there would be write access to the root partition in the chroot.
It does not matter anyway, because the files are owned by root and BIND 9
On Dec 25, Rick Younie [EMAIL PROTECTED] wrote:
Last I heard the usenet group is unidirectional mail - news
and was a little flakey at that.
I seen no problem in the gating process. Please explain what's wrong.
And yes, messages of morons who mail long base 64 encoded files to
mailing lists
On Dec 29, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
What do people think?
Go for it. The OOM killer will hit just about anything which is not a kernel
thread, and losing syslogd and klogd is a major no-no.
The OOM code is supposed to be fixed in 2.4 kernels.
I still see no reason
On Jan 01, Eduard Bloch [EMAIL PROTECTED] wrote:
Huch, apt-get install xfonts-base-transcoded and you have fixed fonts
with latin15 charset. And visit:
You also have lot of troubles... After installing transcoded fonts and
setting [EMAIL PROTECTED] the default font used by gtk applications is
On Jan 02, Paul Dwerryhouse [EMAIL PROTECTED] wrote:
Maybe I'm missing something here, but it's actually quite annoying to
Yes, you are.
echo 'en_AU.ISO8859-15 ISO-8859-15' /etc/locale.gen
locale-gen
have to change the LANG environment variable in order to access the Euro
symbol.
You may
On Jan 31, Joey Hess [EMAIL PROTECTED] wrote:
Oh, so it's udev that's responsible for what IIRC is a race that can
cause X to not see the ps/2 mouse if the module is loaded as part of X's
setup? Nice design. :-P
This is the *upstream* design... The official word on this is that if
you manually
On Jan 31, David Pashley [EMAIL PROTECTED] wrote:
Surely the solution is for hotplug/discover to load it during bootup.
Could hotplug use mdetect?
No. The kernel should implement proper serio support (and maybe until
it's done ship an aliases file which will make hotplug always load
psmouse if
On Aug 21, Colin Watson [EMAIL PROTECTED] wrote:
Now that we have crypto in main, I think we should have fewer -ssl
packages, not more.
Agreed.
--
ciao,
Marco
[Removed postfix-users.]
What vacation is that, it seems very small, my binary on Linux is
45521b
This is not Sean Rima's package but a port of the netbsd source with a
few features added.
(I have no idea about what is wrong with libdb and not time to
investigate it right now, sorry.)
--
On Nov 27, Colin Walters [EMAIL PROTECTED] wrote:
where can i find gpg-agent? is it packaged for debian? if not, then
i'll file an ITP unless someone has valid things to say against that.
Have you looked at quintuple-agent?
Yes, it does not work well.
--
ciao,
Marco
pgpJEumUmpXWb.pgp
On Nov 29, martin f krafft [EMAIL PROTECTED] wrote:
from the current packager i had to hear that it's largely unstable.
many bugs and such. we'll have to wait...
I have been using it for weeks without any problem, so I'd say it should
be packaged. (No, I'm not going to do it.)
--
ciao,
Marco
On Nov 30, Nick Phillips [EMAIL PROTECTED] wrote:
I'm with Joey on this; last time I tried to find Debian .iso images, it
was a nightmare. In fact I couldn't find an official woody iso anywhere.
This is the way of mirror operators to tell you that you should really
use jigdo or even better the
On Jul 05, paddy [EMAIL PROTECTED] wrote:
http://www.senderbase.org/?searchBy=ipaddresssb=1searchString=140.211.166.43showRBL=1
Is there a better way to do this ?
We would need smarter users, and people would need to stop using spamcop
do block mail.
(I had it delisted.)
--
ciao,
Marco
On Jul 08, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote:
Feel free to add any other wishlists (or discuss any one of them). I'll try
to track the subsequent thread and keep the list current somewhere...
Make hotplug depend on udev (this simplifies a lot the hotplug scripts).
--
On Jul 08, Wouter Verhelst [EMAIL PROTECTED] wrote:
Feel free to add any other wishlists (or discuss any one of them). I'll
try
to track the subsequent thread and keep the list current somewhere...
Make hotplug depend on udev (this simplifies a lot the hotplug scripts).
No you
On Jul 08, Wouter Verhelst [EMAIL PROTECTED] wrote:
* was far too fragile, with races all over the place which make some
things work correctly some of the time and not at all on the next
reboot,
The solution to these problems is to use RUN rules (what once were dev.d
scripts).
* requires
On Jul 17, Elimar Riesebieter [EMAIL PROTECTED] wrote:
comfortable to build curl against gnutls in general? Any hints?
Upstream developers should get a clue and either properly license their
software, stop using libcurl or adding gnutls support to it.
--
ciao,
Marco
signature.asc
I am considering switching the init scripts of my packages to lsb-base
(which means that it will have to be promoted to important priority, at
least).
If anybody has objections please voice them now.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Jul 17, Petter Reinholdtsen [EMAIL PROTECTED] wrote:
I already did this for discover1, but did this in a way to make it use
lsb-base only if it is installed.
I can't see the point. The package is tiny, so if it should be used then
everybody should install it.
--
ciao,
Marco
signature.asc
On Jul 18, Bernhard R. Link [EMAIL PROTECTED] wrote:
Is there a way to configure this to not create masses of processes and
confusing the user with colors?
You can write your own package which conflicts+provides lsb-base and
implements /lib/lsb/init-functions.
--
ciao,
Marco
signature.asc
On Jul 20, sean finney [EMAIL PROTECTED] wrote:
i think that would solve the problem by muting the symptoms. what happens
when the next free-but-not-quite-gpl-compatible licensed software is
linked against libcurl (or something similar)?
Not relevant, gnutls is LGPL'ed.
i know i'm repeating
On Jul 21, Francesco P. Lovergine [EMAIL PROTECTED] wrote:
Permission to use, copy, modify, and distribute this software and its
documentation for educational, research and non-profit purposes, without
I don't think it can be distributed at all. Debian does not limit users
of its
On Jul 22, Thomas Hood [EMAIL PROTECTED] wrote:
I have a couple of initscripts that print progress messages and I do
not want to be too hasty in eliminating them so I am thinking of
doing the following for now:
Please don't. lsb-base is a tiny package, either use it or don't.
It will have
On Jul 29, Brian M. Carlson [EMAIL PROTECTED] wrote:
I have found no less than four packages which break with /bin/posh
as /bin/sh, including one that refuses to be removed because of its
brokenness. I am expecting many more.
Yes, like most of my packages.
posh does not provide any benefit
On Jul 29, Steve Langasek [EMAIL PROTECTED] wrote:
Well, please note that posh is not the only shell that lacks support for
local. IIRC, it also breaks down under one or more of dash and busybox sh.
dash supports local, or at least supports it in the way it's used in
all the packages I
On Aug 01, David Weinehall [EMAIL PROTECTED] wrote:
I think we should require that a base install should be POSIX
compliant; for everything else we can be a bit more lax.
I see lack of a rationale here.
But unlike some others, I don't see the point of rejecting patches
to fix
On Aug 01, Thomas Hood [EMAIL PROTECTED] wrote:
Well, if, contrary to fact, the idea were widely supported then posh
could be adapted so that it implemented the minimum set of features
that Debian expected sh scripts to have. Then posh could be used to
test whether scripts were compliant. I
On Aug 01, W. Borgert [EMAIL PROTECTED] wrote:
On Sun, Jul 31, 2005 at 10:07:10PM +, Roland Rosenfeld wrote:
But how do you push the users to remove the package from their
systems? In reality they will keep the broken version installed and
so you have (1) again :-(
Empty package with
On Aug 01, Thomas Hood [EMAIL PROTECTED] wrote:
I would appreciate it if someone would create the potash shell,
consisting of posh modified to implement test -a, test -o and
local. Debian would probably run on that well enough for it to
be used as /bin/sh, and it could become the de facto
On Aug 01, Steve Greenland [EMAIL PROTECTED] wrote:
I personally think it ought to be left as is. Either comply, or change
the first line to #!/bin/bash, which will always be there on Debian
This is pointless because it negates the speed and memory footprint
advantages of dash.
system. Any
On Aug 04, Paul Brossier [EMAIL PROTECTED] wrote:
I would also like to understand. 2.6.12 being available doesn't help.
The package remains un-upgradable from sarge or etch.
Sarge or etch do not have newer versions of udev to upgrade to.
As Manoj and Blars said, solutions would be to have
On Aug 04, Andreas Metzler [EMAIL PROTECTED] wrote:
I would appreciate it if someone would create the potash shell,
consisting of posh modified to implement test -a, test -o and
local. Debian would probably run on that well enough for it to
be used as /bin/sh, and it could become the de
On Aug 05, Marc Haber [EMAIL PROTECTED] wrote:
It will keep them from using a vulnerable version of the software, and
will probably encourage them to get a fixed version from outside
Debian proper (e.g. volatile).
I am a Debian developer. I am not interested in solutions which are
developed
On Aug 11, Sebastian Kuzminsky [EMAIL PROTECTED] wrote:
People who just want GNU Interactive Tools get what they want. People who
just want Cogito get what they want. People who want both have to learn
a new name for one of them. Seems good to me. Am I missing anything?
Reality? git is the
On Aug 14, John Hasler [EMAIL PROTECTED] wrote:
Does there exist a list of all the packages that install scripts in
/etc/init.d?
Yes, it's called Contents-$ARCH.gz...
--
ciao,
Marco
signature.asc
Description: Digital signature
On Aug 14, W. Borgert [EMAIL PROTECTED] wrote:
as a conclusion of many discussions at DebConf5, I propose to
maintain all packages by teams. A fine way to do this, is by
One size fits all methods are a bad idea. Different packages and
different maintainers have different requirements.
--
On Aug 15, John Goerzen [EMAIL PROTECTED] wrote:
Why not rather move towards a more BSD approach, where any developer
can commit changes to any package? It would work around having the
Any developer can already commit changes to any package. The obvious
problem is that it is very hard to have
On Aug 15, Joerg Sommer [EMAIL PROTECTED] wrote:
is it alright to make a file in /usr/share/PKG/examples executable?
Sure. If it's a script and it's not compressed it should be executable.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Aug 18, Domenico Andreoli [EMAIL PROTECTED] wrote:
should i really let 7.14.0-5 be installed? should i change the soname of
the gnutls variant? i suppose other packages already had this problem,
any wise advice?
Stop building the openssl version *at all*.
Or if some broken program *really*
The (still not uploaded) coldplug package conflicts+depends+provides
hotplug. The issue is that since all the important parts of hotplug are
conffiles they are not deleted when the package is removed, and this
is bad (as in the system will probably not boot bad).
Does a way to force purging the
On Aug 22, Petter Reinholdtsen [EMAIL PROTECTED] wrote:
in parallell. Patch included below. For this change to work as it
should, we need to make sure init.d-scripts are ordered according to
dependency, so scripts needed by other scripts get a earlier sequence
number. And to make it
On Aug 22, Ben Armstrong [EMAIL PROTECTED] wrote:
The (still not uploaded) coldplug package conflicts+depends+provides
hotplug.
Aren't you missing replaces?
Yes, what I actually meant was conflicts+replaces+provides.
My original question still stands:
Is there anything else I can do, other
On Aug 22, Ben Armstrong [EMAIL PROTECTED] wrote:
Which conf files blow things up? The reason I ask is, if it's an init
Just about all of them. Almost all files in the package are conffiles.
script, it should be written to exit if the appropriate binary isn't
found.
The appropriate binary is
(From my blog, with the hope that it will be useful.)
(#100) How coldplug works
Today I installed the coldplug package[0] on my system and verified
that not only it works, but it's also quite fast:
[EMAIL PROTECTED]:~#time /etc/init.d/coldplug start
Starting hotplug subsystem: pci usb pnp ide
On Aug 23, Ben Armstrong [EMAIL PROTECTED] wrote:
script, it should be written to exit if the appropriate binary isn't
found.
The appropriate binary is a conffile as well.
Now, that's not strictly true, is it? /etc/init.d/hotplug
invokes /sbin/hotplug, which almost entirely consists of
On Aug 23, Isaac Clerencia [EMAIL PROTECTED] wrote:
I've just tried it and it has worked really great, except it has not loaded
mousedev module. Everything else has worked, and it's incredible fast (at
It's supposed to, do you mind investigating? Do not delete the
generated events, etc. Try
On Aug 23, Luca Capello [EMAIL PROTECTED] wrote:
And here the results (differences versus hotplug):
As Luca just discovered, it will not work unless you have the
/sbin/udevinitsend binary. Get it from the udev build directory or
install http://incoming.debian.org/udev_0.068-2_i386.deb .
-
On Aug 23, Gustavo Noronha Silva [EMAIL PROTECTED] wrote:
The (still not uploaded) coldplug package conflicts+depends+provides
hotplug. The issue is that since all the important parts of hotplug are
conffiles they are not deleted when the package is removed, and this
is bad (as in the
On Aug 23, Ben Armstrong [EMAIL PROTECTED] wrote:
So, a hotplug event could load and run code (which happen to be in conf
files, and therefore cannot be diverted) in the old hotplug package.
The problem you're facing, it seems, is that while code should be
divertable, conf files aren't, but
On Aug 23, Ben Armstrong [EMAIL PROTECTED] wrote:
On Tue, 2005-08-23 at 19:50 +0200, Marco d'Itri wrote:
The init file does, but /etc/hotplug.d/default/default.hotplug does not.
Why is this file a conffile? I didn't see any obviously configurable
Historical reasons? It does not really matter
On Aug 24, Ben Armstrong [EMAIL PROTECTED] wrote:
1. kernel hotplug subsystem detects an event
2. kernel dispatches the event handling using the program named
in /proc/sys/kernel/hotplug (default is /sbin/hotplug) passing it any
necessary argument(s) to hotplug
3. /sbin/hotplug dispatches
On Aug 24, Domenico Andreoli [EMAIL PROTECTED] wrote:
in the meanwhile new packages can be built using the gnutls variant of
libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot
be installed at the same time.
What is the point then? They *will* be needed at the same time.
If
On Aug 24, Ben Armstrong [EMAIL PROTECTED] wrote:
This is not strictly needed, but I cannot avoid it until udev will
become mandatory to have hotplug support (is there a consensus on this?).
Could udev be modified to not run the hotplug.d handlers
if /sbin/hotplug is missing? (Or is that
Currently only a very small number of packages using the deprecated
/etc/hotplug.d/ interface is left.
Keeping hotplug.d/ support is both a waste of resources on every system
(multiple programs needs to be run for every event, even if they are not
needed) and makes the transition from hotplug to
On Aug 24, martin f krafft [EMAIL PROTECTED] wrote:
I have two comments: udev is a device node manager, not a hook
system for generic actions to be taking when a device is plugged or
udev has also been the hotplug multiplexer for some time now.
The other comment is that udev is not generally
On Aug 24, Julien BLACHE [EMAIL PROTECTED] wrote:
Two points:
- I am tired of having to revamp the hotplugging framework every
other month;
Not a great point. There has been exactly one other change in the
hotplug API in the past, and it started long ago with a very long
transition period:
On Aug 24, martin f krafft [EMAIL PROTECTED] wrote:
udev has also been the hotplug multiplexer for some time now.
Yeah. Horrible. Will udev become an editor and MTA too, maybe after
etch?
No. But since it had to deal with most events, applying the same process
to the others was a natural
On Aug 25, Nathanael Nerode [EMAIL PROTECTED] wrote:
So can we configure udev to stop managing /dev? This would remove my qualms
Yes, as explained in README.Debian.
It's not well tested, but it should work (at least in unstable).
And another option is to make it use a different dev_root that
On Aug 25, Horms [EMAIL PROTECTED] wrote:
There are some architectures where 2.4 is required, its
because of these that it seems that we are stuck with 2.4 for Etch.
alpha (installer), m68k (2.6 only works on amiga), s390 (installer),
mips, mipsel
What does installer mean? IIRC SuSE
On Aug 25, Frans Pop [EMAIL PROTECTED] wrote:
waldi there is no package to do the configuration
This looks like something which can be easily fixed before the release.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Aug 25, Thiemo Seufer [EMAIL PROTECTED] wrote:
All those popular mips WLAN devices use still 2.4 kernels, some people
started to port some of them to 2.6, but the main hindrance are binary
only (and thus 2.4 only) drivers.
It's not like they are already supported by debian anyway, then.
Is
On Aug 30, Daniel Stenberg [EMAIL PROTECTED] wrote:
In my view, there's only one available work-around for the short to mid
term, and that is to use a separate .so file for libcurl built with GnuTLS.
We know that in the long term we want to use gnutls. So why should it
not be the default for
On Sep 01, Blars Blarson [EMAIL PROTECTED] wrote:
Would it be acceptable to reject or drop more non-spam? (We could
I am uncomfortable with dropping any mail, but I encourage a sensible
policy to reject spam.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sep 02, Paul TBBle Hampson [EMAIL PROTECTED] wrote:
If I've understood correctly, it is because curl expects the client program
or library to -lgnutls or -lopenssl and therefore provide the SSL symbols
to match the symbols which that build of the .so file is expecting.
I hope not, this
On Aug 23, Marco d'Itri [EMAIL PROTECTED] wrote:
(#100) How coldplug works
Update: coldplug is being reimplemented in C and will become part of
udev, so there will not be further developement of the package in this
form.
If you installed coldplug, please purge it and install hotplug again
On Sep 04, Marc Haber [EMAIL PROTECTED] wrote:
spohr is already running a nameserver, so it would have to run on an
alternate port.
Maybe a DNS view only visible from localhost could be used.
No, the point is to use a fast special-purpose daemon instead of BIND.
It can be easily run on
On Sep 05, Joerg Sommer [EMAIL PROTECTED] wrote:
Drop not, but reject. It would be the best, if you can reject spam in
the SMTP dialog.
Actually it's the only possible solution, a 100K msg/day backscatter
source would be quickly widely blacklisted.
--
ciao,
Marco
signature.asc
Description:
Do you people really need to inform all the debian-devel readers of
this?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sep 06, Ondrej Medek [EMAIL PROTECTED] wrote:
Building scripts should also conform to posh or specify /bin/bash. Some time
Wrong. /bin/sh scripts should surely conform to dash, but there is no
point is wasting time with posh.
ago I've rebuild one package (gaim-extendedprefs or
On Sep 08, Sven Luther [EMAIL PROTECTED] wrote:
2) Any argument i may have are only the lame repetition of the opinion of a
single person here on debian-legal.
Indeed, the choice of venue is a fee argument is just that: an
opinion which has at best no clear roots in the DFSG, therefore it
On Sep 08, Sven Luther [EMAIL PROTECTED] wrote:
Indeed, the choice of venue is a fee argument is just that: an
opinion which has at best no clear roots in the DFSG, therefore it
cannot make a license non-free.
Yeah, but there is certainly more than a single person arguing that we should
On Sep 09, Josselin Mouette [EMAIL PROTECTED] wrote:
There is nothing wrong with this, and I'm not a fan of choice of venue
clauses either, but they should try to modify the DFSG then.
Could you explain why DFSG#5 couldn't be invoked in this case?
It does not work this way. If you believe
On Sep 09, Josselin Mouette [EMAIL PROTECTED] wrote:
It does not work this way. If you believe that a license is not free
it's up to you explaining why.
Well, I'm explaining that it isn't free because of DFSG#5. However, it
seems that you are refusing such arguments de facto.
I am refusing
On Sep 09, George Danchev [EMAIL PROTECTED] wrote:
Debian has always been full of software licensed that way ;-) Now you want
(unintentially) to leave possible holes thru new 'a-la sco insane cases' to
enter the scene... all over the world.
Not now. Debian (and I think every other
On Sep 09, George Danchev [EMAIL PROTECTED] wrote:
It does not work this way. If you believe that a license is not free
it's up to you explaining why.
here they are:
So finally we are up to the good old every restriction is a
discrimination argument. Even if in the last two years it has
On Sep 11, Frank Lichtenheld [EMAIL PROTECTED] wrote:
1) generate more device files in the postinst of the package with
mknod (which is a policy violation IIRC)
Right.
2) make makedev produce more of these files (but probably most users
don't need them, at least not on desktop PCs
On Sep 10, George Danchev [EMAIL PROTECTED] wrote:
Not now. Debian (and I think every other distribution) has been
distributing software with this kind of licenses for years, without any
apparent ill effect on users.
Not true. Many licenses that failed to comply with DFSG [0] has not been
On Sep 12, Justin Pryzby [EMAIL PROTECTED] wrote:
This was originally sent to -mentors, but elicited no response, so I'm
reposting here:
I agree with the answer by Peter Samuelson.
Most of the policy requirements about libraries are only relevant if
they are shared among non-cooperating
On Sep 12, Richard Atterer [EMAIL PROTECTED] wrote:
Folks, *please* consider to help with the implementation of the real
solution for libcurl4, i.e. several SSL backends to just one libcurl.so
front-end, without installation conflicts, modular and compatible with
all licenses. See the second
On Sep 12, Richard Atterer [EMAIL PROTECTED] wrote:
I do not believe that it's worth the effort, there are no really good
reasons to use OpenSSL in the long time.
Development effort should be focused on fixing any eventual gnutls bugs
(either in the library itself or in the libcurl glue).
On Sep 13, Olaf van der Spek [EMAIL PROTECTED] wrote:
There isn't? I thought this has been standard GPL lore for a very long
time - if you link to an *interface* which has a GPL-compliant
implementation, it does not matter if you also are incidentally runtime-
compatible with a
On Sep 13, Brian May [EMAIL PROTECTED] wrote:
Oh, BTW, gnutls isn't a complete 100% solution either, IIRC packages
exist that require openssl because the license is GPL incompatible.
No, it has been LGPL'ed since a long time.
--
ciao,
Marco
signature.asc
Description: Digital signature
After having been deprecated for a long time, support for map files in
the /etc/hotplug/usb/ directory will be removed from the udev-hotplug
subsystem. This is scheduled to happen next month, when most of the
current hotplug package will be replaced by a new coldplug program
which will be part of
On Sep 15, Peter Samuelson [EMAIL PROTECTED] wrote:
Bind mounts will work
(mount --bind /etc/passwd /mnt/sarge-chroot/etc/passwd)
but apparently don't support locking all of a file's representations,
What about bind-mounting the /etc/.pwd.lock lock file too?
--
ciao,
Marco
signature.asc
On Sep 15, SZALAY Attila [EMAIL PROTECTED] wrote:
What should I do?
Tell the user to learn how UNIX works, and stop bitching.
AF_UNIX sockets must be created on a rw file system, and a symlink will
not work.
So either he uses udev, or in some way makes his own writeable /dev.
--
ciao,
Marco
On Sep 16, Stephen R Marenka [EMAIL PROTECTED] wrote:
For the record, -O2 seems to work fine. The segfaults only seem to
apply to -O3 and better (at least in my experience).
I wish. See #323016.
--
ciao,
Marco
signature.asc
Description: Digital signature
The new hotplug subsystem cannot handle blacklisting anymore, and now
delegates it to modprobe.
modprobe uses a different syntax, so the old /etc/hotplug/blacklist*
files are not supported anymore.
Considering that the other distributions have no plans to keep
supporting hotplug-style blacklisting
On Sep 19, Faré [EMAIL PROTECTED] wrote:
PROPOSAL 2: ~/.etc/${package_name}/
Renaming every configuration file is insane. Not even worth discussing.
PROPOSAL 3: ~/.run/ ~/.lib/ ~/.share, etc.
As above, except that this even makes ~ more complex to manage.
NB: I've send a similar proposal to
On Sep 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
What about user-installed blacklists? Will the new packages at least try to
convert these from blacklist format to modprobe format?
No (but feel free to send code to do it).
--
ciao,
Marco
signature.asc
Description: Digital
.
+ /etc/hotplug/usb/*.usermap: must be replaced by udev rules.
+ /etc/hotplug/blacklist*: must be replaced by modprobe configuration
directives.
-- Marco d'Itri [EMAIL PROTECTED] Sun, 18 Sep 2005 00:27:31 +0200
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sep 19, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
Easily done. Conflict with all packages providing blacklist entries by
themselves, and convert everything else. This will keep things safe for
sid/etch users at low cost (a few conflicts you have already tracked down
anyway),
On Sep 19, Alastair McKinstry [EMAIL PROTECTED] wrote:
Unlike Marco, I do see a lot of value in reorganising at least _some_ of
the 'configuration' files of users: seperating out .mozilla web caches
and .evolution IMAP caches greatly relieves the size of backups of ~/
directories. If all
On Sep 19, Hendrik Sattler [EMAIL PROTECTED] wrote:
*urgs*, I really hope that this does not mean to get rid of the hotplug
package!
No, but I expect that more and more packages in the future will require
udev.
There are people who like a static /dev and still want hotplug to
properly load
On Sep 20, Bartosz Fenski aka fEnIo [EMAIL PROTECTED] wrote:
What about home-etc[1] approach?
Anything which requires a distribution to modify a very large number of
applications is evil and not worth a discussion.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sep 20, Bartosz Fenski aka fEnIo [EMAIL PROTECTED] wrote:
I don't say it's the only solution, but imho something has to be done to
start fixing mess in ~/.
If you want to do something:
- useful
- which benefits every distribution
- requiring little effort
then start lobbying application
On Sep 21, Nathanael Nerode [EMAIL PROTECTED] wrote:
The absolute minimum functional upgrade path is to Conflict: with all
package versions providing old-style blacklists, and to abort early in
preinst with a loud warning if any user-specified blacklists are present on
the system (much
501 - 600 of 2882 matches
Mail list logo
