Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 11:33:54PM -0400, Matt Zimmerman wrote: Would you knock it off with the flamebait? That wasn't flamebait. You may have disagreed with it, it may have be inaccurate or logically wrong, but it wasn't flamebait. I am not suggesting that anyone be forced to read any number of README.Debian files, just that it will, quite naturally, become part of the package installation process with the help of package management UIs. And I disagree with your suggestion. Can you offer evidence? Not all README.Debians are alike. Many of them contain information of the form here is how Debian's foobar differs from upstream foobar, which you may be familiar with. As such, it is not in case of emergency instructions, but a README in the traditional sense, to be read _before_ using the software. I glanced through the README.Debians on my disk. Out of about 15, 5 or 6 would be helpful to read before using the package; 7 or 8 had some information that might be interesting to someone knowledgable about the software; and a couple were worthless (empty or basically repeated the description.) None of them were essential. If I'm in a documentation reading mood, I may as well pick up the README file and other stuff in the /usr/share/doc/foo directory. I don't see the reason to single out the README.Debian file. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 09:14:52PM -0500, David Starner wrote: People shouldn't have to sift through a bunch of entries of boring and meaningless text (to them, at least :) to get such information... The same being true of README.Debian. Everything in README.Debian should be admin-oriented information, IMHO, in which case it wouldn't be boring and meaningless. Perhaps they had already read it, though, but even so, it's easier to skim through a few paragraphs one has already read than through lots of terse changelog entries. -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 06:51:21PM -0500, Steve Greenland wrote: There is already a standard, reliable way of communicating package changes to the admin. Amazingly enough, it's called a changelog. I usually find them under /usr/share/doc/packagename/... We can't really expect the admins to parse through hundreds of changelogs; But if it becomes common place to list changes in debconf notes, then the admins will be overwhelmed by them as well, if every upgrade leads to 50 new e-mails. I agree that the maintainers would need to pay more attention to the note priorities and locations. Consider what we're talking about: A package is moving files from one directory to another, and replacing the original directory with a symlink to the new one (assuming that's what Elie decides to do). Why does every admin need to be notified? Ah, in this case it is indeed not necessary to notify the admin. -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 07:46:52PM -0400, Matt Zimmerman wrote: In the future, though, package management frontends should make it easy to view README.Debian at installation time. I agree, a button called Debian README in an X frontend would really be convenient. -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Fri, Sep 14, 2001 at 06:37:08PM -0400, Matt Zimmerman wrote: ...and the new prerm remove it, and future versions of these scripts until the end of ti^W^W^Wrelease after next... Actually, if you'd also ship the symlink in the new .deb, dpkg would remove it. Or am I missing your point? I haven't actually tried this, so I'll take your word for it that dpkg wouldn't complain about the symlink in the new .deb vs. the directory in the filesystem. Yes, it won't complain, but unless you handle it manually it won't create the symlink, it will just leave an empty directory. -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
Steve Greenland [EMAIL PROTECTED] wrote: On 13-Sep-01, 18:37 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Debconf question: do you want a symlink. Please, no. The fact that debconf provides an easy, consistent way to interact with the user does not mean that every possible choice that a package makes needs to ask the user. If I wanted to make all the choices, I'll build from source :-). Either put in the symlink, or don't, but don't bug me about it. Your scheme works, but at least tell the sys admin what is going on with a debconf note. If you don't want to be bugged change the debconf priority. -- Edward Betts (GPG: 1BC4E32B)
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 15-Sep-01, 09:14 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Steve Greenland [EMAIL PROTECTED] wrote: On 13-Sep-01, 18:37 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Your scheme works, but at least tell the sys admin what is going on with a debconf note. If you don't want to be bugged change the debconf priority. I've got it set to high. Apparently a number of maintainers think that every little thing is of high importance. There is already a standard, reliable way of communicating package changes to the admin. Amazingly enough, it's called a changelog. I usually find them under /usr/share/doc/packagename/... Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 11:11:20AM -0500, Steve Greenland wrote: Your scheme works, but at least tell the sys admin what is going on with a debconf note. If you don't want to be bugged change the debconf priority. I've got it set to high. Apparently a number of maintainers think that every little thing is of high importance. You should file bug reports against those. There is already a standard, reliable way of communicating package changes to the admin. Amazingly enough, it's called a changelog. I usually find them under /usr/share/doc/packagename/... We can't really expect the admins to parse through hundreds of changelogs; README.Debian would be a good place, though. -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 08:24:32PM +0200, Josip Rodin wrote: We can't really expect the admins to parse through hundreds of changelogs; README.Debian would be a good place, though. OTOH, apt-listchanges displays the changelog upon upgrade, whereas there's no automated way to display changes to README.Debian. I rarely read README.Debian after first installation, so IMO, it's a bad place to put things that change after installation. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 06:34:38PM -0500, David Starner wrote: We can't really expect the admins to parse through hundreds of changelogs; README.Debian would be a good place, though. OTOH, apt-listchanges displays the changelog upon upgrade, whereas there's no automated way to display changes to README.Debian. I rarely read README.Debian after first installation, so IMO, it's a bad place to put things that change after installation. People shouldn't have to sift through a bunch of entries of boring and meaningless text (to them, at least :) to get such information... -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 06:34:38PM -0500, David Starner wrote: On Sat, Sep 15, 2001 at 08:24:32PM +0200, Josip Rodin wrote: We can't really expect the admins to parse through hundreds of changelogs; README.Debian would be a good place, though. OTOH, apt-listchanges displays the changelog upon upgrade, whereas there's no automated way to display changes to README.Debian. I rarely read README.Debian after first installation, so IMO, it's a bad place to put things that change after installation. Currently, most users probably don't read README.Debian unless they have a good reason, so while it's the correct place to put things like this, they aren't always seen. In the future, though, package management frontends should make it easy to view README.Debian at installation time. -- - mdz
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 15-Sep-01, 13:24 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: On Sat, Sep 15, 2001 at 11:11:20AM -0500, Steve Greenland wrote: There is already a standard, reliable way of communicating package changes to the admin. Amazingly enough, it's called a changelog. I usually find them under /usr/share/doc/packagename/... We can't really expect the admins to parse through hundreds of changelogs; But if it becomes common place to list changes in debconf notes, then the admins will be overwhelmed by them as well, if every upgrade leads to 50 new e-mails. Consider what we're talking about: A package is moving files from one directory to another, and replacing the original directory with a symlink to the new one (assuming that's what Elie decides to do). Why does every admin need to be notified? Nothing should break, and there's really nothing the admin needs to do. There's no harm in the symlink. What about this deserves anything more than a note in the changelog? Now if Elie decides that he does what to move the files, but not deal with the symlink, then yes, it does deserve more than a changelog note, because we can expect at least some people will have things stop working. No, I don't actually expect most users/admins to read every changelog: I certainly don't. But *any* channel that gets overused loses significance, I'd hate to see that happen to debconf. Steve -- Steve Greenland [EMAIL PROTECTED]
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sun, Sep 16, 2001 at 01:49:34AM +0200, Josip Rodin wrote: People shouldn't have to sift through a bunch of entries of boring and meaningless text (to them, at least :) to get such information... The same being true of README.Debian. I like to know what changes on my box, so I can anticipate problems (like this one), so the changelog is usually more interesting than the README.Debian. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 07:46:52PM -0400, Matt Zimmerman wrote: Currently, most users probably don't read README.Debian unless they have a good reason, so while it's the correct place to put things like this, they aren't always seen. In the future, though, package management frontends should make it easy to view README.Debian at installation time. Why? It's not that hard to do less /usr/share/doc/foo/README.Debian, or better yet, cd /usr/share/doc/foo; ls; less whatever. I see no value in having the README.Debian displayed everytime I upgrade xfree86-common, and I seriously doubt I would catch anything important and new. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored. - Joseph_Greg
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 09:18:39PM -0500, David Starner wrote: On Sat, Sep 15, 2001 at 07:46:52PM -0400, Matt Zimmerman wrote: Currently, most users probably don't read README.Debian unless they have a good reason, so while it's the correct place to put things like this, they aren't always seen. In the future, though, package management frontends should make it easy to view README.Debian at installation time. Why? It's not that hard to do less /usr/share/doc/foo/README.Debian, or better yet, cd /usr/share/doc/foo; ls; less whatever. I see no value in having the README.Debian displayed everytime I upgrade xfree86-common, and I seriously doubt I would catch anything important and new. It's not that hard to do this for a single package, but it is a completely different matter to do it by hand for every newly-installed package. This is something that frontends should simplify. In the above text I wrote at installation time, meaning when a package is initially installed, not everytime I upgrade. -- - mdz
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 10:30:21PM -0400, Matt Zimmerman wrote: It's not that hard to do this for a single package, but it is a completely different matter to do it by hand for every newly-installed package. This is something that frontends should simplify. I have over a thousand packages installed, with ~300 README.Debian files. I don't anticipate sitting and reading them all, one after another. And why should I? I just glanced at the xteddy README.Debian; it doesn't work right with sawfish, due to various X arcana. If I were using sawfish and had a problem, that would be one of the first files I read. As I don't run sawfish, I really don't care. In the above text I wrote at installation time, meaning when a package is initially installed, not everytime I upgrade. Which doesn't solve this problem. -- David Starner - [EMAIL PROTECTED] Pointless website: http://dvdeug.dhis.org
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Sat, Sep 15, 2001 at 09:44:23PM -0500, David Starner wrote: On Sat, Sep 15, 2001 at 10:30:21PM -0400, Matt Zimmerman wrote: It's not that hard to do this for a single package, but it is a completely different matter to do it by hand for every newly-installed package. This is something that frontends should simplify. I have over a thousand packages installed, with ~300 README.Debian files. I don't anticipate sitting and reading them all, one after another. Would you knock it off with the flamebait? I am not suggesting that anyone be forced to read any number of README.Debian files, just that it will, quite naturally, become part of the package installation process with the help of package management UIs. And why should I? I just glanced at the xteddy README.Debian; it doesn't work right with sawfish, due to various X arcana. If I were using sawfish and had a problem, that would be one of the first files I read. As I don't run sawfish, I really don't care. Not all README.Debians are alike. Many of them contain information of the form here is how Debian's foobar differs from upstream foobar, which you may be familiar with. As such, it is not in case of emergency instructions, but a README in the traditional sense, to be read _before_ using the software. Information about issues which will affect _new_ users of the software should go there, regardless of whether it has to do with a change from a previous version, because that is where they are supposed to look. Changes which will only affect users of a previous version should display a note if it's important, otherwise just include a changelog entry (which should be there in any case). Upgrading users are not expected to have to read the changelogs _or_ README.Debian to hear about things that will break on their system. -- - mdz
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 13-Sep-01, 18:37 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Debconf question: do you want a symlink. Please, no. The fact that debconf provides an easy, consistent way to interact with the user does not mean that every possible choice that a package makes needs to ask the user. If I wanted to make all the choices, I'll build from source :-). Either put in the symlink, or don't, but don't bug me about it. If you want to put in the symlink, but allow the admin to remove it permanently, do this: 1. If a new install, don't add symlink (no installed base). 2. If upgrading from a version that had /usr/lib/procmail-lib, put in symlink. 3. If upgrading from a (newer) version that did not have /usr/lib/procmail-lib, don't do anything (neither add nor remove symlink). This is easy by looking at the arguments to the postinst and using 'dpkg --compare-versions'. One of the reasons for debconf was to allow for non-interactive installs, but we seem to be going in the wrong direction sometimes. Steve
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Fri, Sep 14, 2001 at 09:23:53AM -0500, Steve Greenland wrote: On 13-Sep-01, 18:37 (CDT), Edward Betts [EMAIL PROTECTED] wrote: Debconf question: do you want a symlink. Please, no. The fact that debconf provides an easy, consistent way to interact with the user does not mean that every possible choice that a package makes needs to ask the user. If I wanted to make all the choices, I'll build from source :-). Either put in the symlink, or don't, but don't bug me about it. Amen! If you want to put in the symlink, but allow the admin to remove it permanently, do this: 1. If a new install, don't add symlink (no installed base). 2. If upgrading from a version that had /usr/lib/procmail-lib, put in symlink. 3. If upgrading from a (newer) version that did not have /usr/lib/procmail-lib, don't do anything (neither add nor remove symlink). This is easy by looking at the arguments to the postinst and using 'dpkg --compare-versions'. Err, why not just test for the existence of directory /usr/lib/procmail-lib ? Is there an advantage to checking the package version instead? -Steve -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Fri, Sep 14, 2001 at 09:23:53AM -0500, Steve Greenland wrote: Please, no. The fact that debconf provides an easy, consistent way to interact with the user does not mean that every possible choice that a package makes needs to ask the user. If I wanted to make all the choices, I'll build from source :-). Either put in the symlink, or don't, but don't bug me about it. If you want to put in the symlink, but allow the admin to remove it permanently, do this: 1. If a new install, don't add symlink (no installed base). 2. If upgrading from a version that had /usr/lib/procmail-lib, put in symlink. 3. If upgrading from a (newer) version that did not have /usr/lib/procmail-lib, don't do anything (neither add nor remove symlink). This is easy by looking at the arguments to the postinst and using 'dpkg --compare-versions'. One of the reasons for debconf was to allow for non-interactive installs, but we seem to be going in the wrong direction sometimes. This is kind of what I was thinking about; thanks. -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 14-Sep-01, 10:18 (CDT), Steve M. Robbins [EMAIL PROTECTED] wrote: Err, why not just test for the existence of directory /usr/lib/procmail-lib ? Is there an advantage to checking the package version instead? Because by the time the postinst runs, /usr/lib/procmail-lib is gone. If it's not there, is it because: a) I'm upgrading from a version that had it (as a directory), and should create the symlink? or b) I'm upgrading from a version that didn't, and the sysadmin has removed the original link (created in case a, above), and I shouldn't create the symlink? You could check in the preinst and cache the result, I suppose, but checking the version is easy: if [ $1 = configure -a -n $2 ] dpkg --compare-versions $2 lt 3.0pl1-43 ; then (replacing 3.0pl1-43 with whatever the first version of procmail-lib is that moves the files from /usr/lib to /usr/share). And it's fast, dpkg doesn't read any of its files for this. Steve
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Thu, Sep 13, 2001 at 12:53:49AM -0400, Matt Zimmerman wrote: Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? This, in particular, won't work, because dpkg won't replace a directory with a symlink. You could, however, replace the files themselves with symlinks, Well, if it was package's own directory, that is, no other packages had ever put stuff in there, the new postinst could just rm -rf it and make it a symlink. -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Fri, Sep 14, 2001 at 10:12:35PM +0200, Josip Rodin wrote: On Thu, Sep 13, 2001 at 12:53:49AM -0400, Matt Zimmerman wrote: Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? This, in particular, won't work, because dpkg won't replace a directory with a symlink. You could, however, replace the files themselves with symlinks, Well, if it was package's own directory, that is, no other packages had ever put stuff in there, the new postinst could just rm -rf it and make it a symlink. ...and the new prerm remove it, and future versions of these scripts until the end of ti^W^W^Wrelease after next... -- - mdz
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Fri, Sep 14, 2001 at 04:18:22PM -0400, Matt Zimmerman wrote: Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? This, in particular, won't work, because dpkg won't replace a directory with a symlink. You could, however, replace the files themselves with symlinks, Well, if it was package's own directory, that is, no other packages had ever put stuff in there, the new postinst could just rm -rf it and make it a symlink. ...and the new prerm remove it, and future versions of these scripts until the end of ti^W^W^Wrelease after next... Actually, if you'd also ship the symlink in the new .deb, dpkg would remove it. Or am I missing your point? -- 2. That which causes joy or happiness.
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Fri, Sep 14, 2001 at 10:50:42PM +0200, Josip Rodin wrote: On Fri, Sep 14, 2001 at 04:18:22PM -0400, Matt Zimmerman wrote: ...and the new prerm remove it, and future versions of these scripts until the end of ti^W^W^Wrelease after next... Actually, if you'd also ship the symlink in the new .deb, dpkg would remove it. Or am I missing your point? I haven't actually tried this, so I'll take your word for it that dpkg wouldn't complain about the symlink in the new .deb vs. the directory in the filesystem. When I had to do something similar with clisp, I sidestepped the issue by symlinking the handful of files rather than the directory itself. It was worth the small price of having the old directory continue to be present in the .deb in order to avoid having to handle the whole bit in the maintainer scripts (and deal with the bugs that almost always crop up). Has anyone considered teaching dpkg how to handle this situation? One possible solution would probably involve tracking type information (file/directory/symlink) for filesystem objects rather than just names, and allowing these to be slightly out of sync with the actual representation in the filesystem (e.g., waiting until nothing is left under a directory, except perhaps symlinks to the new location, and replacing it with a symlink). I seem to recall that 'stow' had a relatively smart mechanism for expansion/collapse of symlinks that solved a related problem. -- - mdz
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Wed, Sep 12, 2001 at 10:51:04PM -0400, Elie Rosenblum wrote: Question regarding this new bug on procmail-lib that I adopted recently: [snip copy of my bug report] I would happily move it to /usr/share, however I am worried about users who are already using the current version. Users can use the provided recipes with the procmail INCLUDERC directive, and if I move the files it will break all of the user rcfiles that already use these includes. Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? I would really rather avoid breaking every rcfile that currently uses any of these recipes. This, in particular, won't work, because dpkg won't replace a directory with a symlink. You could, however, replace the files themselves with symlinks, and if you decide that it is important enough to transparently preserve backward compatibility, I would recommend that you do that. The files themselves would be in the correct place, and the documentation should direct new users to reference them in the new location, and the symlinks could be used for the sake of compatibility. Regardless of whether you create the symlinks, you should definitely display a warning note (via debconf) to the admin upon upgrading from an older version of the package, advising them of the change and encouraging them to update any procmail configs which include recipes from procmail-lib. Then, perhaps in a future release, you may decide to remove any compatibility links, having given fair warning to the administrator (compare the /usr/doc-/usr/share/doc transition plan). My real philosophical difficulty here is that this is a weird case - it is unlikely to burn admins, for whom I could add a notice of this during package upgrade; I am worried about the users in general. You can't take too much direct responsibility for the users; you should keep the admin well-informed, and let them communicate/deal with the users. In some sites, the admin might silently fix all of the users' configurations; at another, they might send out an email announcement telling them to do it themselves; another admin might leave it up to the users to fix their configurations. As the Debian maintainer, you can't be aware of local policy. -- - mdz
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On Thu, Sep 13, 2001 at 12:53:49AM -0400, Matt Zimmerman wrote: On Wed, Sep 12, 2001 at 10:51:04PM -0400, Elie Rosenblum wrote: Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? I would really rather avoid breaking every rcfile that currently uses any of these recipes. This, in particular, won't work, because dpkg won't replace a directory with a symlink. You could, however, replace the files themselves with symlinks, and if you decide that it is important enough to transparently preserve backward compatibility, I would recommend that you do that. Good point, I hadn't gotten that far yet. Thanks. My real philosophical difficulty here is that this is a weird case - it is unlikely to burn admins, for whom I could add a notice of this during package upgrade; I am worried about the users in general. You can't take too much direct responsibility for the users; you should keep the admin well-informed, and let them communicate/deal with the users. In some sites, the admin might silently fix all of the users' configurations; at another, they might send out an email announcement telling them to do it themselves; another admin might leave it up to the users to fix their configurations. As the Debian maintainer, you can't be aware of local policy. I was worried about bonehead admins who would just consider, I'm not using that myself, and ignore the note. I guess, however, it is the admins right to screw over their own users. It was the very fact that I can't be aware of local policy that had me worried. :) I'll probably follow your recommendations, barring anybody else piping up with something we've overlooked. -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
On 13-Sep-01, 10:27 (CDT), Elie Rosenblum [EMAIL PROTECTED] wrote: On Thu, Sep 13, 2001 at 12:53:49AM -0400, Matt Zimmerman wrote: On Wed, Sep 12, 2001 at 10:51:04PM -0400, Elie Rosenblum wrote: Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? I would really rather avoid breaking every rcfile that currently uses any of these recipes. This, in particular, won't work, because dpkg won't replace a directory with a symlink. You could, however, replace the files themselves with symlinks, and if you decide that it is important enough to transparently preserve backward compatibility, I would recommend that you do that. Hmmm, I thought that had been fixed, but I may be thinking of something else. Good point, I hadn't gotten that far yet. Thanks. But what you can do is add the symlink in the postinst. This would mean failures while the install was processing, but then again, so would no symlink at all :-). -- Steve
Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
Elie Rosenblum [EMAIL PROTECTED] wrote: I would happily move it to /usr/share, however I am worried about users who are already using the current version. Users can use the provided recipes with the procmail INCLUDERC directive, and if I move the files it will break all of the user rcfiles that already use these includes. Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? I would really rather avoid breaking every rcfile that currently uses any of these recipes. Debconf question: do you want a symlink. -- Edward Betts (GPG: 1BC4E32B)
Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib
Question regarding this new bug on procmail-lib that I adopted recently: - Forwarded message from Matt Zimmerman [EMAIL PROTECTED] - Subject: Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib Reply-To: Matt Zimmerman [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 12 Sep 2001 20:37:25 -0400 From: Matt Zimmerman [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: procmail-lib Version: 1:1997.07.22-1 Severity: serious Being architecture-independent data, the .rc files supplied by procmail-lib should go under /usr/share, not /usr/lib. See Debian Policy 10.1.1, FHS 4.4, 4.7 -- System Information Debian Release: unstable Architecture: i386 Kernel: Linux mizar 2.4.8 #1 Sat Aug 18 20:31:53 EDT 2001 i686 Locale: LANG=C, LC_CTYPE=en_US Versions of packages procmail-lib depends on: ii perl [perl 5.6.1-5 Larry Wall's Practical Extraction ii procmail 3.21.20010830.really.3.15.2-2 Versatile e-mail processor. -- - mdz - End forwarded message - Matt is correct, and if I was packaging from scratch that is how I would have done it; however, I adopted this package in its state. I would happily move it to /usr/share, however I am worried about users who are already using the current version. Users can use the provided recipes with the procmail INCLUDERC directive, and if I move the files it will break all of the user rcfiles that already use these includes. Would turning /usr/lib/procmail-lib into a symlink to the appropriate location be acceptable? I would really rather avoid breaking every rcfile that currently uses any of these recipes. My real philosophical difficulty here is that this is a weird case - it is unlikely to burn admins, for whom I could add a notice of this during package upgrade; I am worried about the users in general. -- Elie Rosenblum That is not dead which can eternal lie, http://www.cosanostra.net And with strange aeons even death may die. Admin / Mercenary / System Programmer - _The Necronomicon_
