On Mon, Apr 16, 2012 at 7:15 PM, Arno Töll wrote:
> On 16.04.2012 18:59, Olaf van der Spek wrote:
>> Defining a standard for vhosts would solve the problem without having
>> to touch the normal doc root. Seems like a far simpler fix.
>
> how would you do that? We can'
On Mon, Apr 16, 2012 at 7:21 PM, Arno Töll wrote:
> Hi,
>
> On 16.04.2012 18:56, Olaf van der Spek wrote:
>> On Sun, Apr 15, 2012 at 1:14 PM, Paul Wise wrote:
>>> /srv is solely the domain of the sysadmin, packages cannot rely on any
>>> particular layout n
On Sun, Apr 15, 2012 at 5:49 PM, Arno Töll wrote:
>> I'd use ht instead of html. Not every ht file is a html file.
>
> I have no strong opinion on the actual name, as long as it is another
> subdirectory. We could equally use /var/www/default, /var/www/htdocs or
> whatever we feel like.
What abou
On Sun, Apr 15, 2012 at 1:14 PM, Paul Wise wrote:
> /srv is solely the domain of the sysadmin, packages cannot rely on any
> particular layout not specified by the sysadmin (via debconf etc).
I know. Is that a problem though?
AFAIK packages don't (and shouldn't) put any files into vhost dirs.
-
On Sun, Apr 15, 2012 at 1:12 PM, Thomas Goirand wrote:
>> I'd use ht instead of html. Not every ht file is a html file.
>>
>> We should consider vhosts as well. Lighttpd defaults to
>> /srv//htdocs (for mod simple vhost). ht instead of htdocs might
>> be better.
>>
>> We could use /srv/default/ht
On Sun, Apr 15, 2012 at 2:25 AM, Arno Töll wrote:
> Thus, to summarize once again: I'd like to change the default directory
> served by web servers from /var/www to /var/www/html along with
> remaining web servers in Debian.
>
> Comments?
I'd use ht instead of html. Not every ht file is a html fi
On Mon, Mar 28, 2011 at 6:43 PM, John H. Robinson, IV wrote:
>> Compatible with what? Bugs in other implementations?
>> What does that really gain us?
>
> The ability for the discs to be read on as many systems as possible. I'm
> not going to pretend to know what all someone else may need to do wi
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV wrote:
>> That's not our problem, is it?
>
> It is, if we are trying to be as compatible as possible.
Compatible with what? Bugs in other implementations?
What does that really gain us?
--
Olaf
--
To UNSUBSCRIBE, email to debian-devel-req
On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre wrote:
>>Why's that? Isn't UDF widely supported?
>
> Implementations often widely differ in their limitations - see the
> Wikipedia page for more details. The suggested way to make a safe UDF
> DVD is often along the lines of "use the ISO9660 bridge
On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre wrote:
>>64 is quite low. Is there no way to use longer filenames that still
>>works on all required platforms?
>
> To do that, we'll have to switch to a different filesystem. That's a
> possibility (maybe UDF), but there's probably even more of a ch
On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre wrote:
> users. The problem is that Joliet has a limit for filename length (64
> characters), and technically we're already past that length. From
> genisoimage.1:
64 is quite low. Is there no way to use longer filenames that still
works on all requ
On Fri, Mar 4, 2011 at 12:35 PM, Stefano Zacchiroli wrote:
> On Wed, Mar 02, 2011 at 11:54:05AM -0800, Steve Langasek wrote:
>> At present there *is* no reliable sysadmin interface for enabling/disabling
>> services. update-rc.d is not it; many admins have been using 'update-rc.d
>> -f remove' fo
On Mon, Mar 21, 2011 at 5:42 PM, Simon McVittie wrote:
> The data package typically just takes up space without doing anything
> useful if you install it on its own, so it should have the
> special::auto-inst-parts debtag and should usually Recommend the library or
> executable.
I don't agree. Ye
On Sun, Mar 20, 2011 at 7:43 AM, Raphael Geissert wrote:
>> | In particular, considering the possibility of other init systems coming
>> | (see #591791), would /usr/sbin/service enable/disable still be a proper,
>> | init-system-independent, abstraction?
>>
>> I'm guessing service would have to le
On Fri, Mar 18, 2011 at 3:10 PM, Bernhard R. Link wrote:
>> Like say: In 10+ years I have never ever seen a single rar file
>> unrar-free could unpack but thousands that needed unrar/rar.
>
> If that was true then unrar-free should be dropped and everything
> depending on it be removed, too, or mo
On Fri, Mar 18, 2011 at 12:11 AM, Russell Coker wrote:
>> Then don't use the option. It should definetly be an option:
>
> It's a pity that there is no kernel support for synching one filesystem (or
> maybe a few filesystems).
That'd be only a partial work around. Even with a single fs one big
sy
On Tue, Mar 15, 2011 at 4:51 PM, Bernd Zeimetz wrote:
> On 03/15/2011 04:17 PM, Lucas Nussbaum wrote:
>> Indeed, I don't know why we bother with packages at all.
>
> Thanks for your constructive comment.
He's right though. With packages, you can receive automatic
notification of available updates
On Mon, Mar 14, 2011 at 2:17 PM, Ben Hutchings wrote:
> On Mon, 2011-03-14 at 09:17 +0100, Sebastian Harl wrote:
> [...]
>> > > Would it be fine to do that in postinst?
>> >
>> > It must be done in postinst, and you may need to fall back to setuid if
>> > the filesystem does not support setcap.
>>
On Wed, Mar 9, 2011 at 11:09 AM, Adam Borowski wrote:
>> Or is it actually so that the libc should map uses of epoll_create1 to
>> epoll_create? Or do we need to introduce run-time checks as to whether
>> epoll_create1 is available?
>
> There's no way around run-time checks if you want to be safe
On Sun, Mar 6, 2011 at 4:36 PM, Joachim Breitner wrote:
> I have a bit a bad feeling about not being able to use alternatives in
> build-depends. For example at the moment, we are renaming a self-hosting
> compiler package from ghc6 to ghc. Previously, the dependency has been
> on "ghc6". Now it i
On Fri, Mar 4, 2011 at 3:59 PM, Klaus Ethgen wrote:
> In ancient times debian was packaged the way that the administrator only
> installed the daemons that he needed. Today many daemons gets installed
> by dependencies and gets started without any need. Just the fact is
> security relevant as any
On Fri, Mar 4, 2011 at 1:23 PM, Ben Hutchings wrote:
> You could stop being lazy and type the dot on the end too. ;-)
You can't expect everyone to type a dot after every single domain name they use.
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsu
On Fri, Mar 4, 2011 at 12:35 PM, Stefano Zacchiroli wrote:
> Right, this is the technical problem to solve: find one (handy) method
> to enable/disable services and "bless" it as the recommended one.
What do other distros use?
It seems to be chkconfig, not service (for this functionality).
Olaf
On Thu, Mar 3, 2011 at 7:32 PM, Phillip Susi wrote:
>> And we use some linux specific ioctl to avoid that fragmentation.
>
> Could you be more specific?
sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WRITE);
sync_file_range(fd.a, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE);
Olaf
--
To UNSUBSCRIBE,
On Thu, Mar 3, 2011 at 1:16 PM, Lars Wirzenius wrote:
> On to, 2011-03-03 at 12:47 +0100, Bastien ROUCARIES wrote:
>> some package announce their existance to the world without any admin
>> decision!
>> It is not a fud and a security hole!
>
> That's a vague generality... which packages? You men
On Thu, Mar 3, 2011 at 7:25 AM, Tollef Fog Heen wrote:
> - install daemon
> - install configuration using puppet/chef/cfengine/etc
> - start daemon or hook daemon into tool that keeps it running (monit,
> god, etc)
Can't you either install the config before installing the daemon or
just do a dae
On Thu, Mar 3, 2011 at 8:33 AM, Marius Vollmer wrote:
> And in the big picture, all we need is some guarantee that renames are
> comitted in order, and after the content of the file that is being
> renamed. I have the impression that all reasonable filesystems give
> that guarantee now, no?
No,
On Tue, Mar 1, 2011 at 7:25 PM, Sean Finney wrote:
> well, for starters the interface sucks from a sysadmin point of view
> compared to stuff like chkconfig/service. i also think that there's (a
> perhaps shrunken, haven't checked in a while) set of things that you
> just can't do with update-rc.
On Tue, Mar 1, 2011 at 5:13 PM, Steve Langasek wrote:
> On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote:
>> On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote:
>> >> Isn't update-rc.d the way to configure the rc.d scripts?
>
>> > No,
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote:
>> Isn't update-rc.d the way to configure the rc.d scripts?
>
> No, it's a way for *maintainer scripts* to manage init scripts.
>
>> Or am I old-fashioned.
>
> You are using an interface that was never meant for administrator use.
> Nowadays th
2011/3/1 ximalaya :
> I notice that, valgrind reports memory leaks against some frequently used
> commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps
> -ef, ls -latr, top, etc.
For short-running processes that's generally not a problem.
--
Olaf
--
To UNSUBSCRIBE, email to
On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
wrote:
>> But there is an ordering choice. local has priority.
>
> By default, we assume the local administrator knows what he is doing.
>
> That is not going to change.
Sure. But Sergey has a good point: why are there no bin and lib in
On Mon, Feb 28, 2011 at 12:04 AM, Peter Samuelson wrote:
> Unfortunately (from your perspective) there is not a way to configure a
> default library search path differently for binaries in different
> places. So if you want /usr/local/bin binaries to see /usr/local/lib
> by default (that's what D
On Sun, Feb 27, 2011 at 7:45 PM, Fernando Lemos wrote:
> Those are valid points, of course, but many Boost projects will fail
> to build now and I see no good solution[1][2][3]. Some libraries like
I do: http://en.wikipedia.org/wiki/Auto-linking
First has to be implemented in GCC though.
--
Ol
On Sat, Feb 19, 2011 at 10:49 AM, Olaf van der Spek
wrote:
> On Fri, Feb 18, 2011 at 9:19 AM, Stephen Gran wrote:
>> I don't want to prolong this thread, but this seemed useful to answer.
>>
>> I certainly have no intention of changing the default on my own.
>
On Fri, Feb 25, 2011 at 9:55 AM, Peter Palfrader wrote:
> We should probably start a campaign in Debian to have all init scripts
> sanitize the environment of daemons they start.
>
> I usually run initscripts using "env -i /etc/init.d/$foo start" to
> achieve exactly that, but ideally the init scr
On Sat, Feb 19, 2011 at 11:43 AM, Roger Leigh wrote:
> We could even do the opposite (create a "public" folder) if the
> permissions are 0750, though this would require either 0751 or
> ACLs to be actually accessible. Again, we could include a README file
> instructing the user how to do this.
O
On Fri, Feb 18, 2011 at 9:19 AM, Stephen Gran wrote:
> I don't want to prolong this thread, but this seemed useful to answer.
>
> I certainly have no intention of changing the default on my own.
Could you at least fix the original bug and ensure preseeding works?
Olaf
--
To UNSUBSCRIBE, email
On Sat, Feb 19, 2011 at 9:10 AM, Marc Haber
wrote:
>>On Thu, Feb 17, 2011 at 01:44:26PM +, Ian Jackson wrote:
>>> Perhaps it might be reasonable to try to find a way for accounts like
>>> msql and www-data not to be able to access home directories (add
>>> "daemon" to their supplementary group
On Fri, Feb 18, 2011 at 2:26 PM, Noel David Torres Taño
wrote:
> On Jueves 17 Febrero 2011 22:18:25 Ron Johnson escribió:
>> On 02/17/2011 08:58 AM, Roger Leigh wrote:
>> [snip]
>>
>> > Should it be locked down like Fort Knox?
>>
>> There's a heck of a lot of middle ground between "Fort Knox" and
On Thu, Feb 17, 2011 at 4:24 PM, Roger Leigh wrote:
> On Thu, Feb 17, 2011 at 04:07:12PM +0100, Olaf van der Spek wrote:
>> On Thu, Feb 17, 2011 at 3:58 PM, Roger Leigh wrote:
>> > In general, I think it's fair to say that the average Debian
>> > installation does
On Thu, Feb 17, 2011 at 3:58 PM, Roger Leigh wrote:
> In general, I think it's fair to say that the average Debian
> installation does not require Fort Knox levels of security. Simply
> allowing other people to read our files is often something desirable;
Does other refer to other users, all oth
On Thu, Feb 17, 2011 at 3:38 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: Default Homedir Permissions"):
>> chmod 755 ~ is not a hard way to remove the barrier.
>
> We are arguing about defaults, so this is not a relevant answer.
In both cases it's easy t
On Thu, Feb 17, 2011 at 2:44 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Default Homedir Permissions"):
>> Default homedir permissions are 755. World-readable (and listable).
>> Common (security) sense says that permissions that are not required
>> sho
On Thu, Feb 17, 2011 at 1:52 PM, Martin Wuertele wrote:
> IIRC you are asked during installation if you want world readable home
> directories or not.
No you're not. Unless (I assume) you do an expert install. Even then,
non-world-readble means 751, not 750. The default should still change.
--
O
Hi,
Default homedir permissions are 755. World-readable (and listable).
Common (security) sense says that permissions that are not required
should not be granted. For example, accounts mysql and www-data should
not have access to my documents.
Some time ago I filed a bug related to this: 398793
T
On Tue, Feb 15, 2011 at 6:04 PM, Mark Hymers wrote:
> Could we choose to document that it can only be used in wheezy (enforced
> by dak if necessary) and above and then have the release notes state
> that users must upgrade dpkg and apt to the latest point release before
> doing the dist-upgrade?
On Mon, Feb 14, 2011 at 3:38 PM, Tollef Fog Heen wrote:
> ]] Petter Reinholdtsen
>
> | I believe we need to come up with a way where most or all package
> | maintainers (perhaps those handling kernel events and early boot stuff
> | should be expected) only need to maintain one boot setup for their
On Sun, Feb 13, 2011 at 12:58 PM, Roger Leigh wrote:
> • adding build conflicts to ensure it will build on any arbitrary
> system with a random selection of installed packages will always be
> on a "best effort" basis:
Is this about automatically picking up optional dependencies (by
configure a
On Sat, Feb 12, 2011 at 3:06 PM, Andrey Rahmatullin wrote:
>> 128MB would work reasonably.
> I think that VPS'es with 128Mb RAM are still sold, not to mention existing
> installations.
May enable it on x64 first (those 128 mb VPSs are unlikely to run x64)
and then see about other archs later.
--
On Fri, Feb 4, 2011 at 12:47 PM, Fernando Lemos wrote:
>> This is possible, however, it is an extra busy work for a user. In any
>> case, I think that holding a lock only for downloading is an overkill
>> and this can be relaxed.
>
> As far as I can tell (and please correct me if I'm wrong), when
On Fri, Feb 4, 2011 at 9:57 AM, Stanislav Maslovski
wrote:
> This is possible, however, it is an extra busy work for a user. In any
> case, I think that holding a lock only for downloading is an overkill
> and this can be relaxed.
What if you would launch two download-only ops at the same time?
I
2011/2/1 Jesús M. Navarro :
> So, may I propose (if not already done) a document that outlines with enough
> detail what Debian maintenance policy is and why from an upstream point of
> view, and then allow for within Stable upgrades for software that has
> demonstrated to pursue the same standards
On Sat, Jan 29, 2011 at 1:53 PM, Ted Ts'o wrote:
> On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote:
>>
>> Is there a way to log cases where (potentially) unsafe writes happen?
>> Cases like truncation of an existing file, rename on a target that's
On Fri, Jan 28, 2011 at 3:26 AM, Ted Ts'o wrote:
> On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote:
>> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
>> wrote:
>> > BTW: KDE4 is a very good example for failure with modern filesystems. I
>&
On Wed, Jan 26, 2011 at 7:25 PM, Hendrik Sattler
wrote:
> Zitat von "Olaf van der Spek" :
>
>> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
>> wrote:
>>>
>>> BTW: KDE4 is a very good example for failure with modern filesystems. I
>>>
On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
wrote:
> BTW: KDE4 is a very good example for failure with modern filesystems. I
> regularly loose configuration files when suspend-to-ram fails even if the
> configuration of the running programs were not changed. Yay :-( And this is
> with XFS, no
On Wed, Jan 26, 2011 at 5:09 PM, Goswin von Brederlow wrote:
> typedef struct {
> int fd;
> char buffer[];
> } safe_t;
>
> or what do you mean by invalid C?
Zero length arrays are not valid C AFAIK.
--
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Wed, Jan 26, 2011 at 11:36 AM, Goswin von Brederlow
wrote:
> I think you are dead wrong there Ian. Even if every single program is
> dead right (and we know a lot aren't) that means every one of them has
> a safe file update function somewhere in it.
>
> A function doing exactly the same thing
On Wed, Jan 26, 2011 at 12:22 PM, Adam Borowski wrote:
>> typedef struct {
>> int fd;
>> char buffer[PATH_MAX];
>> } safe_t;
>
> Except, you can't rely on PATH_MAX on any modern system. It's defined in
> Linux headers to an arbitrary value to make old code compile, but for
> examp
On Fri, Jan 21, 2011 at 5:39 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: packages with hook interfaces and no
> documented hook policy"):
>> On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote:
>> > If you have better suggestions how to solve this
On Fri, Jan 21, 2011 at 1:04 PM, Michael Vogt wrote:
> If you have better suggestions how to solve this problem, I'm happy to
> hear (and implement) them. Until then I would recomment that you run
> the upgrade manually so that you have control over when exactly it
> happens.
An alternative would
On Wed, Jan 19, 2011 at 9:27 AM, Nikita V. Youshchenko wrote:
> Then, maybe explicitly request upstream - at appropriate forums and in
> appropriate polite wording - to help debian team(s) to handle the bug
> report stream?
I think upstream has the same problem in some cases: too many bug reports
On Tue, Jan 18, 2011 at 10:41 AM, Michael Biebl wrote:
> On 18.01.2011 06:08, Joey Hess wrote:
>> Michael Biebl wrote:
>>> Also; You said, the hook breaks suspend/hibernate. I don't agree this is the
>>> case. If there is no upgrade running, the hook will exit immediately.
>>> If there is an upgra
On Sun, Jan 16, 2011 at 3:54 AM, Russ Allbery wrote:
> It's the responsibility of packages to clean up obsolete conffiles as
> they're upgraded. If you run into the case of a package that's been
> upgraded and not cleaned up its obsolete conffiles, and there isn't some
> reason for that, that's w
On Sun, Jan 16, 2011 at 2:47 AM, Mike Bird wrote:
> On Sat January 15 2011 16:33:28 Olaf van der Spek wrote:
>> If insserv meses up so bad, shouldn't it be able to detect that things
>> will go wrong too?
>
> insserv completely discards the Snn/Knn values and generates a
On Sat, Jan 15, 2011 at 11:39 PM, Mike Bird wrote:
> I have looked at the release notes, what little documentation there
> is, and much but not all of the source code.
>
> It would certainly help if a warning were included in the release
> notes but the most critical fix is to the misleading state
On Sat, Jan 15, 2011 at 10:13 AM, Stéphane Glondu wrote:
> Le 15/01/2011 01:05, Roger Leigh a écrit :
>> This is mostly due to removed packages which need fully purging to
>> remove the last traces of old init scripts which break the process.
>
> I've already experienced issues with configuration
On Fri, Jan 14, 2011 at 12:51 PM, Alexander Reichle-Schmehl
wrote:
> Hi!
>
> Am 13.01.2011 11:54, schrieb Olaf van der Spek:
>
>>> Now we just need to define what a proper job is.
>> Instead of stepping down, it might be better to ask for a co-maintainer.
On Thu, Jan 13, 2011 at 2:25 PM, Stefano Zacchiroli wrote:
> On Thu, Jan 13, 2011 at 02:03:07PM +0100, Olaf van der Spek wrote:
>> > Remember: there is no shortage of bug reports.
>>
>> That's unfortunately true. Why is it that bug squashing parties only
>>
On Thu, Jan 13, 2011 at 1:40 PM, Ian Jackson
wrote:
> Remember: there is no shortage of bug reports.
That's unfortunately true. Why is it that bug squashing parties only
happen a short time before release while it appears that the rest of
the time the issue is ignored?
--
Olaf
--
To UNSUBSC
On Thu, Jan 13, 2011 at 11:27 AM, Sune Vuorela wrote:
> On 2011-01-13, Felipe Sateler wrote:
>> We can't demand or require anyone to do anything. Yet we expect
>
> I think this is mostly wrong.
>
> We can demand or require people to step down. And we should if we don't
> think they do a proper jo
On Thu, Jan 13, 2011 at 1:38 AM, Ian Jackson
wrote:
> But in this case I don't think we should be "expecting" maintainers to
> necessarily shepherd bug reports upstream. I don't think a maintainer
> who fails to do so is failing in their job as maintainer.
>
> The maintainer should decide whether
On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela wrote:
>> Will this mean that the problem will somehow disappear from Debian? Because
>> if it's a problem detected within Debian it's my feeling that it will have to
>> be tracked within Debian till the problem is in Debian no more.
>
> No. but it i
On Sun, Jan 9, 2011 at 5:31 PM, Stefan Fritsch wrote:
>> Shouldn't libapache2-mod-php5 be deprecated in favor of PHP via
>> FastCGI anyway? Would avoid this and other issues.
>
> mod_php won't go away quickly.
Why not?
> But having an out-of-the box usable
> php+fastcgi configuration in squeeze+
On Thu, Jan 6, 2011 at 7:59 PM, Enrico Weigelt wrote:
> * Olaf van der Spek schrieb:
>
>> A transaction to update multiple files in one atomic go?
>
> Yes. The application first starts an transaction, creates/writes/
> removes a bunch of files and then sends a commit. The ch
On Sun, Jan 9, 2011 at 10:14 AM, Stefan Fritsch wrote:
> No. Apache unloads and reloads modules on a graceful restart, unless a
> modules takes special measures to prevent that. You can check that
> with lsof or checkrestart. But libapache2-mod-php5's behaviour is not
> optimal for other reasons (
On Thu, Jan 6, 2011 at 7:33 PM, Enrico Weigelt wrote:
> To come back to the original question, I'd like to know which concrete
> realworld problems should be solved by that. One thing an database-like
> transactional filesystem (w/ MVCC) would be nice is package managers:
> we still have the probl
On Thu, Jan 6, 2011 at 5:01 AM, Ted Ts'o wrote:
> On Thu, Jan 06, 2011 at 12:57:07AM +, Ian Jackson wrote:
>> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
>> > Then I invite you to implement it, and start discovering all of the
>> > corner cases for yourself. :-) As I predicted, you're
On Thu, Jan 6, 2011 at 1:54 AM, Ted Ts'o wrote:
>> I was thinking, doesn't ext have this kind of dependency tracking already?
>> It has to write the inode after writing the data, otherwise the inode
>> might point to garbage.
>
> No, it doesn't. We use journaling, and forced data writeouts, to
>
On Wed, Jan 5, 2011 at 10:37 PM, Ted Ts'o wrote:
>> Ah. So performance isn't the problem, it's just hard too implement.
>> Would've been a lot faster if you said that earlier.
>
> "Too hard to implement" doesn't go far enough. It's also a matter of
> near impossibility to add new features later.
On Wed, Jan 5, 2011 at 7:26 PM, Ted Ts'o wrote:
> On Wed, Jan 05, 2011 at 12:55:22PM +0100, Olaf van der Spek wrote:
>> > If you give me a specific approach, I can tell you why it won't work,
>> > or why it won't be accepted by the kernel maintainers (for examp
On Wed, Jan 5, 2011 at 3:15 PM, Roger Leigh wrote:
> I doubt it. The symlink doesn't work right now due to the same file
> being present on both paths, causing one to be overwritten. Once that
> issue is solved, it should not impact upon keeping /usr separate. As
> long as a feature such as sep
On Wed, Jan 5, 2011 at 1:18 PM, Roger Leigh wrote:
>> You're right. Is there a project goal for this yet?
>
> No, that's one of the reasons I've brought it up.
>
> Practically speaking, this can be done fairly easily. There's no
> need to ban having a separate /usr at all. Having /usr as a symli
On Wed, Jan 5, 2011 at 1:25 AM, Ted Ts'o wrote:
> On Wed, Jan 05, 2011 at 01:05:03AM +0100, Olaf van der Spek wrote:
>>
>> Why is it that you ignore all my responses to technical questions you asked?
>>
>
> In general, because they are either (a) not well-forme
On Wed, Jan 5, 2011 at 1:25 AM, Roger Leigh wrote:
> Well, that's the issue at hand. The reason I mentioned this is
> because I believe that the / and /usr separation is a case where we
> should stop to consider the "bigger picture" rather than just the
> immediate problem. Solving that would sol
On Mon, Jan 3, 2011 at 3:43 PM, Ted Ts'o wrote:
> On Mon, Jan 03, 2011 at 12:26:29PM +0100, Olaf van der Spek wrote:
>>
>> Given that the issue has come up before so often, I expected there to
>> be a FAQ about it.
>
> Your asking the question over (and over... an
On Tue, Jan 4, 2011 at 8:45 PM, brian m. carlson
wrote:
> Because lots of programs expect something like
>
> fd = open("/tmp/foo", O_WRONLY|O_CREAT|O_EXCL);
> unlink("/tmp/foo");
> write(fd, "data", 4);
>
> to succeed. This is how Unix filesystem semantics work and pretty much
> always have.
On Tue, Jan 4, 2011 at 7:19 PM, Ian Jackson
wrote:
> Having said that, I don't think the concept behind your library is
> sound, because it presupposes that all previous programs which update
> files are buggy.
They are. Kinda. They either do unsafe file updates or they have
regressions from the
On Tue, Jan 4, 2011 at 7:29 PM, Steve Langasek wrote:
> On Tue, Jan 04, 2011 at 06:51:13PM +0100, Olaf van der Spek wrote:
>> On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim wrote:
>> > Maybe we're talking at cross-purposes here; I was speaking about the
>> > ca
On Tue, Jan 4, 2011 at 7:20 PM, Ian Jackson
wrote:
> Olaf van der Spek writes ("Re: Source code"):
>> Renaming open files works, so that should no longer be a problem.
>
> They have to be able to be deleted.
Why?
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ..
On Tue, Jan 4, 2011 at 7:13 PM, Samuel Thibault wrote:
>> > dpkg doesn't care, but shlibdeps does care, hurd-i386 has been bitten by
>> > that enough to make us give up with /usr -> /.
>>
>> Why couldn't shlibdeps be fixed?
>
> We kept fixing it, and at some point (where it became really not obvio
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault wrote:
> Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit :
>> I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really
>> unpacks to /lib/libm.so due to /usr -> / symlink,
>
> dpkg doesn't care, but shlibdeps does care, hurd-
On Tue, Jan 4, 2011 at 6:39 PM, Samuel Thibault wrote:
> Steve Langasek, le Tue 04 Jan 2011 09:34:45 -0800, a écrit :
>> I don't agree. dpkg doesn't need to care that /usr/lib/libm.so really
>> unpacks to /lib/libm.so due to /usr -> / symlink,
>
> dpkg doesn't care, but shlibdeps does care, hurd-
On Tue, Jan 4, 2011 at 6:49 PM, Sven Joachim wrote:
> Maybe we're talking at cross-purposes here; I was speaking about the
> case of turning a directory into a symlink on upgrades, which cannot
> safely be done while there are still files under it.
>
> Thinking more about it, this cannot be done e
On Tue, Jan 4, 2011 at 3:30 PM, Nikita V. Youshchenko wrote:
>> On Mon, Jan 03, 2011 at 04:55:52PM -0800, Don Armstrong wrote:
>> > On Tue, 04 Jan 2011, Stephen Grant Brown wrote:
>> > > I would like to install dpkg under Windows Vista.
>> >
>> > This is almost certainly going to be an exercise in
On Tue, Jan 4, 2011 at 2:40 PM, Tollef Fog Heen wrote:
> | What about .so files needed before /usr is mounted?
>
> Do you have a non-contrived example of a .so file which is needed before
> /usr is mounted and where there's a need for a static library?
Why the second part of that condition?
Olaf
On Tue, Jan 4, 2011 at 1:42 PM, Tollef Fog Heen wrote:
> | Eh, wouldn't this case be a valid use case?
>
> No, there's no reason for the .so to live in /lib rather than /usr/lib.
What about .so files needed before /usr is mounted?
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.de
On Tue, Jan 4, 2011 at 9:38 AM, Tollef Fog Heen wrote:
> ]] Roger Leigh
>
> | On Mon, Jan 03, 2011 at 10:33:21PM +0100, Olaf van der Spek wrote:
>
> | > I've never used pkgconfig. But if it doesn't support it, it too should be
> fixed.
>
> First, it's
On Mon, Jan 3, 2011 at 8:06 PM, Andreas Metzler
wrote:
>> What's the problem with fixing automake?
>
> Hello,
>
> in a nutshell: I doubt anybody who has the knowledge to fix it cares,
> and there is more to it than a
> --with-stuff-usually-in-libdir-but-we-want-it-below-urs=/usr/lib.
> Installing
1 - 100 of 422 matches
Mail list logo
