Bug#689948: ITP: libproc-wait3-perl -- Perl interface to wait3() system call
Package: wnpp Severity: wishlist Owner: Alessandro Ghedini * Package name: libproc-wait3-perl Version : 0.4 Upstream Author : Curt Tilmes * URL : http://search.cpan.org/dist/Proc-Wait3/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl interface to wait3() system call Proc::Wait3 is a Perl extension that provides access to the wait3 system call, which is used to wait for state changes in child processes. Differently from wait, wait3 additionally returns child's resource usage information. -- 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/20121008085517.30625.38619.reportbug@dexter
Bug#689950: ITP: libserver-starter-perl -- superdaemon for hot-deploying Perl server programs
Package: wnpp Severity: wishlist Owner: Alessandro Ghedini * Package name: libserver-starter-perl Version : 0.12 Upstream Author : Kazuho Oku * URL : http://search.cpan.org/dist/Server-Starter/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : superdaemon for hot-deploying Perl server programs It is often a pain to write a server program that supports graceful restarts, with no resource leaks. Server::Starter solves the problem by splitting the task into two. One is start_server, a script provided as a part of the module, which works as a superdaemon that binds to zero or more TCP ports or unix sockets, and repeatedly spawns the server program that actually handles the necessary tasks (for example, responding to incoming commenctions). The spawned server programs under Server::Starter call accept(2) and handle the requests. . To gracefully restart the server program, send SIGHUP to the superdaemon. The superdaemon spawns a new server program, and if (and only if) it starts up successfully, sends SIGTERM to the old server program. -- 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/20121008092202.13140.5814.reportbug@dexter
Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?
On 10/08/2012 01:21 AM, Julien Cristau wrote: On Fri, Oct 5, 2012 at 23:16:05 +0200, Andreas Beckmann wrote: Hi, I haven't made a detailed analysis, yet, and cannot say how many packages would be affected. Right now I have about 100 candidate piuparts logs that should cover /var/run and /var/lock, but I haven't sorted them in "buggy", "depends on buggy", "other problem". I expect the buggy category to be around a dozen. Would it be appropriate to file RC bugs against all the packages shipping anything in /var/run, /var/lock or /run? No, there's nothing wrong with that. Cheers, Julien Lintian (and myself) do not agree with you. Lintian considers it a "Serious" problem. And so does the policy manual in which you can read: "Packages must not include files or directories under /run, or under the older /var/run and /var/lock paths." It's perfectly fine to me that the release team decides what is RC or not (even if I don't agree, it's your call...), but these are still "must not" in the wording of the policy. Cheers, Thomas -- 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/5072abf8.6030...@debian.org
Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?
On 08/10/2012 12:33, Thomas Goirand wrote: > On 10/08/2012 01:21 AM, Julien Cristau wrote: >> On Fri, Oct 5, 2012 at 23:16:05 +0200, Andreas Beckmann wrote: >> >>> Hi, >>> >>> I haven't made a detailed analysis, yet, and cannot say how many >>> packages would be affected. Right now I have about 100 candidate >>> piuparts logs that should cover /var/run and /var/lock, but I >>> haven't sorted them in "buggy", "depends on buggy", "other >>> problem". I expect the buggy category to be around a dozen. >>> >>> Would it be appropriate to file RC bugs against all the packages >>> shipping anything in /var/run, /var/lock or /run? >>> >> No, there's nothing wrong with that. >> > […] > > It's perfectly fine to me that the release team decides what is RC or > not (even if I don't agree, it's your call...), […] Julien answered the question though and you don't seem to disagree (by reading your mail). -- Mehdi Dogguy مهدي الدڤي -- 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/5072ad96.30...@dogguy.org
Bug#689959: ITP: libpithub-perl -- Github v3 API
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpithub-perl Version : 0.1016 Upstream Author : Johannes Plunien * URL : http://search.cpan.org/dist/Pithub/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Github v3 API Pithub is a Perl module to provide access to Github v3 API in an object oriented way. This module does not support older version of Github API. This module is a dependency of new version of padre git plugin -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.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/201210081400.30630@debian.org
Metapackages - What to do with them? (was: debian-ctte Re: Bug#688772: gnome Depends network-manager-gnome)
I am posting this on -devel because I think that it rather belongs here than in the context of #681834 and the discussion in -ctte On Sat, Oct 06, 2012 at 09:41 +0200, Josselin Mouette wrote: > Le vendredi 05 octobre 2012 à 22:07 -0600, Bdale Garbee a écrit : > > I personally believe that metapackages should be primarily populated > > with Recommends, with Depends largely reserved for actual technical > > dependencies between real packages. I would like to point you to the last time this suggestion was discussed in debian-devel [0] as it contains a number of arguments that might otherwise go unnoticed. Unfortunately this issue/thread is an amalgamation of a number of independent issues and it might make sense to discuss them independently. I can easily make out the following: 1. Is the action to change the network manager dependency in the gnome metapackage in the spirit of the CTTE resolution? 2. What is the relation between GNOME and network manager (NM). How tightly do they *need* to be coupled and what are the technical/usability implications of using GNOME without it. 3. Interoperability of NM with other network configuration mechanisms/tools such as /etc/network/interfaces, wicd, manual configuration, ... and in particular bugs therein. (i.e. What happens if NM gets installed even though the administrator configured the network in a different way) 4. How should metapackages be implemented and how should they be treated by apt? 5. How should the Desktop task be installed during the initial installation and how can users tweak that? There are probably more, but these pop into my head right now. I do not want to comment on (1) but it might make sense to discuss the others first as that might very well make a CTTE resolution redundant. I also can not gauge (2) and would be happy if members of the Gnome team could comment on that, but (3) should clearly be discussed within the scope of applicable bug reports that can then be fixed. As you might have guessed it is mostly (4) and (5) that are most important to me and it would IMHO be beneficial to discuss this in a broader scope (maybe in debian-policy) and codify the decision in the policy. 1. Motivation for a change - What is the problem? = The main motivation for a change to the current implementation was given in [0], the DEP-6 discussion [1] and by Bdale: >> This is consistent with my belief that we should try to empower our users >> to be able to exercise a reasonable amount of choice in configuring and >> operating their Debian systems. A common argument formulated by the GNOME team (or members thereof) is: > Maybe you are unfamiliar with what clueless newbies do with their > systems. You want to empower users, that’s fine; but GNOME is for all > users. Those who have the technical knowledge to handle their packages > manually should also know how to make it happen without metapackages. which is certainly true, but doesn't capture one *very* important aspect. Sure "clueless users" won't really care and are happy to get a GNOME installation that packs everything and the kitchen sink. This is good IMHO and encourages exploration of different software options in a unified and well integrated environment. It is also true that "advanced users"/"power users"/Debian Members/Unix beards/… can easily finetune their installation or even create new personal metapackages, but … The problematic use case are users who are proficient enough with Debian to realise that they do not want a set of packages and who try to remove them, but who do not (yet) know enough about Debian and its actual implementation to do so. The current implementation makes it incredibly hard (see [2] for "solutions") to finetune a "kitchen sink" systemi). I think that the wish to explore and finetune a system is typical for new users who get familiar with their system and they should be encouraged and supported in doing so. 2. What can be done? Two proposals are commonly made to rectify the situation: 1. Use Recommends in metapackages 2. Treat metapackages differently during removal/purge After thinking about this I am still convinced that (2.1) is the better solution as it allows users to remove some packages that were pulled in by a matapackage without causing its complete removal. I dislike (2.2) because it means that "apt-get install METAPKG ; apt-get purge METAPKG" does not (in terms of installed packages) change anything. It would essentially mean that there is no inverse element/action for "install". Arguments against (2.1) comprise: * Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. [3] Not sure about this and Josselin unfortunately did not elaborate on actual problems. * […] there is the problem that versione
Bug#689961: ITP: ltrsift -- postprocessing and classification of LTR retrotransposons
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: ltrsift Version : 1.0.1 Upstream Author : Sascha Steinbiss * URL : http://www.zbh.uni-hamburg.de/LTRsift * License : GPL Programming Lang: C Description : postprocessing and classification of LTR retrotransposons LTRsift is a graphical bioinformatics tool for semi-automatic postprocessing of de novo predicted LTR retrotransposon annotations, such as the ones generated by LTRharvest and LTRdigest (included in the genometools package). Its user-friendly GTK interface displays LTR retrotransposon candidates, their putative families and their internal structure in a hierarchical fashion, allowing the user to "sift" through the sometimes large results of de novo prediction software. It also offers customizable filtering and classification functionality. List of features: * wizard-guided project creation and automated pre-classification * "drag-and-drop'' manual family assignment * candidate filtering based on dynamic, customizable rule sets, defined in a simple programming language (Lua) * reference matching against custom FASTA files (BLAST required) * ORF detection * concise, customizable visualization of candidate structure * candidate lists can be sorted by column values -- 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/20121008124731.29833.35442.reportbug@eden.localdomain
Bug#689963: ITP: ibus-libpinyin -- Intelligent Pinyin engine based on libpinyin for IBus
Package: wnpp Severity: wishlist Owner: Asias He * Package name: ibus-libpinyin Version : 1.4.92 Upstream Author : Peng Huang BYVoid Peng Wu * URL : https://github.com/libpinyin/ibus-libpinyin * License : GPL2 Programming Lang: C++, Python Description : Intelligent Pinyin engine based on libpinyin for IBus It includes a Chinese Pinyin input method and a Chinese ZhuYin (Bopomofo) input method based on libpinyin for IBus. -- 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/20121008134937.16094.65401.reportbug@debian
Re: assumptions about the build environment.
Jakub Wilk writes ("Re: assumptions about the build environment."):
> More questions about build env assumptions:
My answers:
> Can you assume that /sbin and /usr/sbin are within PATH?
No. Package builds are supposed to be done as the user; the rootness
of the "install" target is just for file permissions and doesn't mean
it should be using admin tools.
> Can you assume that the SHELL environment variable (_not_ the makefile
> variable) is set to something §10.4-compliant?
No. SHELL might refer to ksh, csh or even emacs.
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/20594.62821.442938.293...@chiark.greenend.org.uk
Question about debian experimental.
Hello! I have a question. Since maintainers of LXDE are extremely busy last few months I would like to find a way to upload latest upstream version of libfm and pcmanfm into experimental repository. I feel sorry that I constantly bug the maintainers with the same question and I think they already hate me that I ask them despite they are still have no time for that. So I would like do not bore them anymore. I have all the required debian/* files which are files from 0.1.17 / 0.9.10 versions with some corrections needed to conform Debian Policy rules where they were not and adapted to all what was changed in upstream. Packages made with those files are proven to be created and installed smoothly on Wheezy. Those debian/* files are public available on https://github.com/LStranger/. Why I would like to upload them into experimental? That is simple - I would like to let people in Debian BTS who are struggling from bugs that prevent them from usage of old versions of pcmanfm to get current version which is free of all those bugs. So question is - may it be possible to upload them into experimental or I have still to bother maintainers? I feel sorry to do that again. Thank you very much. Andriy. -- 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/20121008163046.ge23...@rep.kiev.ua
Re: Question about debian experimental.
Andrej N. Gritsenko wrote: [new LXDE] >So question is - may it be possible to upload them into experimental > or I have still to bother maintainers? I feel sorry to do that again. Hello, an upload to experimental needs to be signed by a Debian Developer[1], there is no real difference to uploading to unstable in this respect. cu andreas [1] or a DM enabled for this package -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- 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/1oebk9-5m3@argenau.downhill.at.eu.org
Re: Question about debian experimental.
On Tue, Oct 9, 2012 at 12:30 AM, Andrej N. Gritsenko wrote: > I have a question. Since maintainers of LXDE are extremely busy last Perhaps you would like to join the LXDE package maintainers team and help them out? They don't appear to be using the pkg-lxde group on alioth though, so best contact them to find out how best to help. You can also help them by triaging bugs in their packages: http://bugs.debian.org/lxde-deb...@lists.lxde.org http://wiki.debian.org/BugTriage -- 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 Archive: http://lists.debian.org/CAKTje6E_LQeQsnVp2p5drV-XwP=z4ewk2SVG=Sq=zar2b0u...@mail.gmail.com
Bug#689980: ITP: sweethome3d-furniture-editor -- Sweet Home 3D Furniture Library Editor
Package: wnpp Severity: wishlist Owner: Gabriele Giacone <1o5g4...@gmail.com> * Package name: sweethome3d-furniture-editor Version : 1.8 Upstream Author : Emmanuel Puybaret, eTeks * URL : http://www.sweethome3d.com * License : GPL-2+ Programming Lang: Java Description : Sweet Home 3D Furniture Library Editor Sweet Home 3D is an interior design Java application for quickly choosing and placing furniture on a house 2D plan drawn by the end-user, with a 3D preview. . This package contains furniture library editor for creating your own libraries. -- 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/20121008174816.GA7573@phenomenon
Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?
On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote: > On 10/08/2012 01:21 AM, Julien Cristau wrote: >>> Would it be appropriate to file RC bugs against all the packages >>> shipping anything in /var/run, /var/lock or /run? >>> >> No, there's nothing wrong with that. >> >> Cheers, >> Julien > > Lintian (and myself) do not agree with you. Lintian > considers it a "Serious" problem. And so does the policy > manual in which you can read: > > "Packages must not include files or directories under /run, > or under the older /var/run and /var/lock paths." The thing is that it really does no harm if a package actually does this; although it is pretty pointless since those files will be gone after reboot. So, even though policy says "must not", it's not really a problem in practice, so important is probably a more appropriate severity at this point in the release process. Best wishes, Mike -- 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/CANTw=MO8SnuhQBRHmw9mQke8GZv0YTVNrz-mpcPgq-=bjgy...@mail.gmail.com
Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?
* Michael Gilbert , 2012-10-08, 14:15: "Packages must not include files or directories under /run, or under the older /var/run and /var/lock paths." The thing is that it really does no harm if a package actually does this Given that /var/lock is world-writable in Debian, and that dpkg follows symlinks to directories, at least shipping directories in /var/lock is almost certainly a security hole. (Fortunately, this is mitigated by the protected_symlinks feature of the recent kernels.) -- Jakub Wilk -- 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/20121008182724.ga2...@jwilk.net
Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]
On 08.10.2012 20:15, Michael Gilbert wrote: > On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote: >> "Packages must not include files or directories under /run, >> or under the older /var/run and /var/lock paths." > > The thing is that it really does no harm if a package actually does > this; although it is pretty pointless since those files will be gone I actually find it pretty handy if I can use dpkg -S to find out which package a particular directory belongs to. So shipping the directory in the package does have some value (at least for me). aba rightfully pointed out, that having a mechanism in dpkg which allows one to register such a directory in the dpkg database dynamically, might be an even better approach. Such a mechanism could not only be used to register such volatile files/directories in (/var)/run or /lock but files that are generated by the maintainer scripts like ucf config files or even ressources like system users and groups. 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: Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]
Hi! On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote: > On 08.10.2012 20:15, Michael Gilbert wrote: > > On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote: > >> "Packages must not include files or directories under /run, > >> or under the older /var/run and /var/lock paths." > > > > The thing is that it really does no harm if a package actually does > > this; although it is pretty pointless since those files will be gone > > I actually find it pretty handy if I can use dpkg -S to find out which > package a particular directory belongs to. > So shipping the directory in the package does have some value (at least > for me). That applies as well to any path generated at maintainer script or run time by the package (like state, cache, log files, etc), but I don't think it's currently a good idea for these to belong in the dpkg database, as either the files' md5sums might change over time, or the paths might appear and disappear if they are on a ramfs, or worse might cause security issues if they are world writable (like /var/lock, as Jakub has pointed out). > aba rightfully pointed out, that having a mechanism in dpkg which allows > one to register such a directory in the dpkg database dynamically, might > be an even better approach. > > Such a mechanism could not only be used to register such volatile > files/directories in (/var)/run or /lock but files that are generated by > the maintainer scripts Sure, and that's been on the dpkg TODO list for a while, but it needs first for its database to be extended to track additional metadata. I was planning on working on this for 1.17.x anyway. > like ucf config files This will be covered instead by extending the dpkg conffile support to allow to register external configuration files. > or even ressources like system users and groups. I'm not entirely sure what you mean with this though, maybe something like #685734? thanks, guillem -- 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/20121008205332.ga13...@gaara.hadrons.org
Re: where is the DNSSEC root key?
When unbound is installed, the root key is at /var/lib/unbound/root.key. The init script updates it, if requsted, by way of unbound-anchor(8). Ideally there would be a separate package each dnssec-aware package could depend on which would maintain the root.key file. For comparison, gentoo has a net-dns/dnssec-root package which installs /etc/dnssec/root-anchors.txt and .xml. That would be a good precedent to follow. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- 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/m3obkczipi@carbon.jhcloos.org
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
2012/9/18 Jon Dowland wrote: >> There's no need to walk through the minefield, it's already done. >> Fedora lost more than half of the user base with the Fedora 15 >> release (GNOME3 and systemd). > > [citation-needed] Good point. Initially it was a personal feeling. Many fedora users I know have switched to CentOS/ScientificLinux/Ubuntu/Mint/etc after Fedora15 release. A few others just use old Fedora14 manually updating it when needed. Among those still using Fedora15+ most GNOME users switched to XFCE/LXDE. But those "users I know" are still not too much to talk about all users. So I did some research. Fedora provides a nice stats page: https://fedoraproject.org/wiki/Statistics The best part of it is IP stats per release. After some manual digging through the history of that page I was able to build a chart (attached) comparing some sort of popularity among releases. I understand that it's not perfect. But I don't know any better. For a good chart I need raw stats data which Fedora doesn't provide (yet?) Fedora lost about 40% in popularity comparing just F14 and F15. But acceptance of F15 release was ~3 times worse than F14. ~80% of users stayed on F14, after F15 release. On the other hand only ~30% were loyal to F15. The other 70% dropped F15 as soon as F16 was out. Now, 2 years after release, F14 is still on top by the number of IPs, after F8. Looks like the case of F8 vs F9 is going to repeat again (F9 was a KDE4+upstart release, F15 was GNOME3+systemd). PS: I wish Debian had a similar stats page. It's now possible with http.debian.org. -- Serge <>
Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?
On 10/09/2012 02:15 AM, Michael Gilbert wrote: The thing is that it really does no harm if a package actually does this; although it is pretty pointless since those files will be gone after reboot. So, even though policy says "must not", it's not really a problem in practice, so important is probably a more appropriate severity at this point in the release process. Best wishes, Mike I don't agree. Imagine for a minute that we have 2 implementation of the same service. Lets say, for this example, MariaDB and MySQL (this is *not* a real world example, since last time I checked, we don't have MariaDB in Debian but it well could be a real problem). Both MySQL and MariaDB would use and implement /var/run/mysql/mysql.sock. If both were installable at the same time, then shipping /var/run/mysql would create a useless conflict, while they could really live together (of course, not started at the same time, but living on the same filesystem, giving the user the option to switch from one to another as wished). So it *is* a very practical problem. I know at least that multiple packages are using /var/run/ircd for example. On 10/09/2012 04:02 AM, Michael Biebl wrote: I actually find it pretty handy if I can use dpkg -S to find out which package a particular directory belongs to. So shipping the directory in the package does have some value (at least for me). Well, the problem *IS* that dpkg knows about the folder when it should absolutely not. Cheers, Thomas -- 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/5073a4c3.80...@debian.org
Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?
On Tue, 09 Oct 2012, Thomas Goirand wrote: > Imagine for a minute that we have 2 implementation of the same service. > Lets say, for this example, MariaDB and MySQL (this is *not* a real world > example, since last time I checked, we don't have MariaDB in Debian but > it well could be a real problem). Both MySQL and MariaDB would use and > implement /var/run/mysql/mysql.sock. If both were installable at the same > time, then shipping /var/run/mysql would create a useless conflict, while > they could really live together (of course, not started at the same time, > but living on the same filesystem, giving the user the option to switch from > one to another as wished). > > So it *is* a very practical problem. I know at least that multiple packages > are using /var/run/ircd for example. And? It's perfectly possible to share directories between multiple packages. The fact that /var/run/mysql/ would be owned by multiple packages is no different from the fact that /var/run/ is already owned by multiple packages: $ dpkg -S /var/run base-files, isc-dhcp-client, uml-utilities, dnsmasq-base: /var/run It's *not* a problem. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20121009065356.gd3...@x230-buxy.home.ouaza.com
