Re: [DNG] /usr to merge or not to merge... that is the question??
Le 20/11/2018 à 11:32, Rick Moen a écrit : Quoting Didier Kryn (k...@in2p3.fr): Well, AFAIU, you compile your own kernel, with device drivers in the kernel, instead of modules (not possible for all), and don't use the packaged kernel/initrd provided by Debian. That's not _precisely_ what I said, no. (I have nothing against modules, after all.) As I already mentioned immediately upthread, I compile drivers essential for my hardware into the kernel image, and a variety of other drivers that I might need but might not as modules. It is absolutely possible to live like this, Well, that's a relief! You had me worried. ;-> I was just acking it's possible (I played that game for embeded devices) :-) ...but it discards apt-controlled kernel updates (typically once per month). Do you _really_ replace your kernel once a month? That seems outlandish, to me. Yes, everytime I run synaptic, I generally apply *all* upgrades, including kernel. I'm not entirely certain what you mean by 'apt-controlled'. A I already mentioned, make-kpkg(1) is an obvious tool for this purpose that constructs a debianised local package, which therefore among other results is fully registered with the package subsystem. Perhaps you should try it. If by 'apt-controlled' you mean 'fetching and running binary debs of someone else's kernel', no, I prefer to run mine, instead. Yes. Do you perform kernel updates, and how? How? Rather well! ;-> And what kernel source do you use, kernel.org or Debian? I'm unclear on what possible use you would have for that information. Just out of curiosity: Debian kernels are patched by Debian's kernel team, in particular for security fixes. Therefore I see 4 options (at least) 1) compile from kernel.org source with your own config 2) compile from kernel.org source with Debian's config, customized by you 3) compile from Debian patched kernel source with your own config 4) compile from Debian patched kernel source with Debians config, customized by you When I played that game, I used option 1, but didn't upgrade frequently the kernel. The devices were well protected inside an intranet. With laptop and desktop computers, I certainly don't want that burden. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] no-usr-merged: let's get concrete
On Mon, Nov 19, 2018 at 12:17:45PM +0100, KatolaZ wrote: [cut] > > Note: the mini.iso is a barebone netinst, and tasksel does not > currently work (I am on that). The "Package selection" step will > fail. Just skip it, continue with the installation, and then install > stuff with apt-get after reboot. > Just to let you know that tasksel has now been fixed in unstable and beowulf, so the "Package selection" step should run smoothly. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Thu, Nov 22, 2018 at 11:16:04AM +1300, Daniel Reurich wrote: > > > > > > Maintaining the option of choosing between the two is what Devuan is > > trying to do, knowing that it might become harder to support it as > > time passes. My guess is that there is no real reason for the basic > > system (the stuff needed at boot time before you get to the point > > where other filesystems are mounted) to be heavily affected by such a > > change, since packagers are not going to hardcode /usr/bin/sh in their > > scripts from tomorrow. > > To be honest I don't even think the option should be presented at > install time - certainly not in the way it's currently being presented > in the installer - adding yet another dialogue. > > I suggest we add it as option in the package-selection to install > usrmerge or drop it altogether. People that care can install usrmerge > at any time post-installation and deal with the consequences. > > (At the rate we're going, we're adding a new dialogue in the installer > per release... soon it will become more tedious to install Devuan then > installing windows...) I would be more inclined towards leaving the dialog more or less as it is but making it only available in the expert install (leaving non-merged-usr as the default). The main problem is that usrmerge (the package) is a hack, which will be discontinued and become unmaintained as soon as merged-usr is declared "standard" (and we have seen this happening already with systemd-shim and libsystemd-dummy, from the same authors of usrmerge). If we provide an choice, it ougth to be a reliable one. Users of expert install won't mind another dialog with the expected default, and will appreciate the added flexibility, IMHO. My2cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Thu, Nov 22, 2018 at 04:12:23AM +0100, Alessandro Selli wrote: > On 21/11/18 at 20:56, Hendrik Boom wrote: > > On Wed, Nov 21, 2018 at 05:24:24PM +0100, Alessandro Selli wrote: > >> On 21/11/18 at 16:59, KatolaZ wrote: > >>> On Wed, Nov 21, 2018 at 07:32:22AM -0800, Rick Moen wrote: > Quoting Roger Leigh (rle...@codelibre.net): > > > I've been following the discussion with interest. > For values of 'following' that equates to noting that the matter has > been discussed, but then ignoring its substance. > > >>> Dear Rick, > >>> > >>> you could have noticed that in essence Roger pointed to the merged-usr > >>> solution as not only impractical, but also risky and of doubtful > >>> usefulness. > >> > >> So, you agree then that: > >> > > ... > > ... > >> 3. "you can't split the package database between separate systems" > >> (whatever this means, who needs to split the package database and > >> why?); > > This is about upgrades using the package manager. > > If there are two /'s > > > Two roots? Like when you have several systems booting on the local > disk but mounting some filesystems, among them /usr, from the same > shared partition/NFS server? Yes, exactly. I'm trying to explain just what is problematic. > > > > sharing one single /usr, when you upgrade, one of the > > /'s will be upgraded consonant with the /usr, and the other will not be. > > How then to upgrade the other /? Its package database will no longer > > be in sync with its /usr. > > > If I got you right, the problem would be that some systems would have > a /usr already updated by another system that performed the update > before it did. This should not be a problem with security updates, the > /usr would just be updated several times, one for each system that uses > the same /usr. A serious problem would arise with a major OS version > upgrade. in this case, a single system should perform the full update > and the others should be put in sync offline. Easier said that done, I > understand, still syncronization is a problem with any number of > independent systems that share something among them. Exactly. > > You do have a point here, a merged / -> /usr would make upgrades > easier on clusters (who said Red Hat?), because it forces them to share > the whole, single filesystem. But the point is that ease of management > of such a cluster is not a good reason to impose a filesystem design > change on everybody else. For all their importance, clusters are a > corner case among the many uses GNU/Linux is deployed for; it is indeed > a good thing that they had the possibility of performing the merge, but > there is no reason desktop installations should be deprived of the > choice to not do the same. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 21/11/18 at 20:56, Hendrik Boom wrote: > On Wed, Nov 21, 2018 at 05:24:24PM +0100, Alessandro Selli wrote: >> On 21/11/18 at 16:59, KatolaZ wrote: >>> On Wed, Nov 21, 2018 at 07:32:22AM -0800, Rick Moen wrote: Quoting Roger Leigh (rle...@codelibre.net): > I've been following the discussion with interest. For values of 'following' that equates to noting that the matter has been discussed, but then ignoring its substance. >>> Dear Rick, >>> >>> you could have noticed that in essence Roger pointed to the merged-usr >>> solution as not only impractical, but also risky and of doubtful >>> usefulness. >> >> So, you agree then that: >> > ... > ... >> 3. "you can't split the package database between separate systems" >> (whatever this means, who needs to split the package database and why?); > This is about upgrades using the package manager. > If there are two /'s Two roots? Like when you have several systems booting on the local disk but mounting some filesystems, among them /usr, from the same shared partition/NFS server? > sharing one single /usr, when you upgrade, one of the > /'s will be upgraded consonant with the /usr, and the other will not be. > How then to upgrade the other /? Its package database will no longer > be in sync with its /usr. If I got you right, the problem would be that some systems would have a /usr already updated by another system that performed the update before it did. This should not be a problem with security updates, the /usr would just be updated several times, one for each system that uses the same /usr. A serious problem would arise with a major OS version upgrade. in this case, a single system should perform the full update and the others should be put in sync offline. Easier said that done, I understand, still syncronization is a problem with any number of independent systems that share something among them. You do have a point here, a merged / -> /usr would make upgrades easier on clusters (who said Red Hat?), because it forces them to share the whole, single filesystem. But the point is that ease of management of such a cluster is not a good reason to impose a filesystem design change on everybody else. For all their importance, clusters are a corner case among the many uses GNU/Linux is deployed for; it is indeed a good thing that they had the possibility of performing the merge, but there is no reason desktop installations should be deprived of the choice to not do the same. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 00:46, Svante Signell wrote: > A historical note: The GNU/Hurd people tried to do the merge the other (and > right) way around: Why are we to take for granted that that way is the right way and that it does make sense for present-day rollouts? [...] > Let's bring som history into this discussion. History does not make IT infrastructure run smoothly. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 22/11/18 at 02:16, Erik Christiansen wrote: > On 21.11.18 17:11, Alessandro Selli wrote: >> On 21/11/18 at 13:17, Roger Leigh wrote: >>> Hi folks, >>> >>> I've been following the discussion with interest. >> >> No, you definitely have not followed it. In fact you are disregarding >> all the points that were expressed against the merge. >> >> >>> It's certainly not a new discussion, since I remember debating it a >>> good few years back, but there are still the same opinions and >>> thoughts on the topic that I remember from back then. >>> >>> Some general points to consider: >>> >>> 1) A separate /usr serves no practical purpose on a Debian/Devuan system >> >> Yes it does, and they were already listed: > +1 > > What amazes me more than the great length of this thread is the > inordinate ignorance of insisting that merging needs to be mandated, > instead of just being offered on an opt-in basis, maximally invisible to > the rest of us. Yes, you're right. This stubborn insistence that disregards any objection and pretends no valid reasons to reject the change was ever debated is stunning, reminds me of talks about politics, not technical matters. I really wonder where people active in the Free Software community got that attitude. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 21/11/18 at 23:16, Daniel Reurich wrote: [...] > To be honest I don't even think the option should be presented at > install time - certainly not in the way it's currently being presented > in the installer - adding yet another dialogue. > > I suggest we add it as option in the package-selection to install > usrmerge or drop it altogether. People that care can install usrmerge > at any time post-installation and deal with the consequences. You're trading an install time dialogue with an install time manual selection. I don't see any actual improvement. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 21/11/18 at 19:04, Rowland Penny wrote: > On Wed, 21 Nov 2018 18:50:42 +0100 > Alessandro Selli wrote: > >> On 21/11/18 at 18:39, Rowland Penny wrote: >>> On Wed, 21 Nov 2018 18:25:02 +0100 >>> Alessandro Selli wrote: >>> On 21/11/18 at 18:15, m712 wrote: >> Of course we are, why don't you read before replying? > I can't be sure if you are in jest. Of course I am not. Dr. Nikolaus Klepp asked: From: "Dr. Nikolaus Klepp" To: dng@lists.dyne.org Date: Wed, 21 Nov 2018 17:22:00 +0100 Message-Id: <201811211722.00535.dr.kl...@gmx.at> Why would anybody hardcode the link to sed in the first place? Isn't that what $PATH is all about? And I answered with a case where the absolute placement of the sed executable does matter and cannot be circumvented with a PATH setting or the use of commands like which or command. What is not clear? >>> You got the context wrong, or as we say here in the UK, you got the >>> wrong end of the stick ;-) >>> >>> He asked 'Why would anybody hardcode the link', what has this to do >>> with a shebang ? >> >> A shebang is an often used construct that would be broken were not a >> link in place. >> >> Do you need a drawing to see why? >> >> >>> You are quite correct, you cannot replace a shebang with 'which', >>> but then, this was never the problem. >> >> Yes, it is. Because shebangs do require a link from /usr/bin >> to /bin were files moved from /bin to /usr/bin. >> >> >>> Did you read the debian bugreport ? >> >> Yes, I did. >> >> Now you, how would you have a #!/bin/Rscript script work without a >> filesystem-level link? >> >> > I repeat, the problem in the bugreport had nothing to do with a shebang, The bug report is about Rscript. Do you know what that is for? It's long being considered good practice on updates letting the system be changed in such a way as to let the old scripts work without modifications. That was a golden rule under Solaris for instance, which explains why they put in /bin and /usr/bin old, non POSIX compliant versions of shells, sed, awk and so forth, with the revised, improved, X/Open standard utilities installed in /usr/xpg4/bin/. Debian broke this golden Unix rule, putting the link on the filesystem from /usr/bin to /bin is the correct VUA remedy to the issue they introduced, because it shifts the responsibility in maintaining the system integrity on updated to the distribution development team, not on users. You're free to disagree of course, but please let me kow if and where are ever you going to take responsibility in maintaining a GNU/Linux distribution or a major package. Or maybe you're going to be a systemd developer, in which case it would be quite all right and actually pretty appropriate. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 21.11.18 17:11, Alessandro Selli wrote: > On 21/11/18 at 13:17, Roger Leigh wrote: > > Hi folks, > > > > I've been following the discussion with interest. > > > No, you definitely have not followed it. In fact you are disregarding > all the points that were expressed against the merge. > > > > It's certainly not a new discussion, since I remember debating it a > > good few years back, but there are still the same opinions and > > thoughts on the topic that I remember from back then. > > > > Some general points to consider: > > > > 1) A separate /usr serves no practical purpose on a Debian/Devuan system > > > Yes it does, and they were already listed: +1 What amazes me more than the great length of this thread is the inordinate ignorance of insisting that merging needs to be mandated, instead of just being offered on an opt-in basis, maximally invisible to the rest of us. All the "woulda coulda shoulda" opinions and pseudo-arguments proffered as justification for foisting one's personal prejudices on others are infinitely irrelevant. Let each choose according to personal perception of merit or any auspicious augury, but choose freely. That said, don't mind me - the fizzy fireworks display may break the thread length record, and spare the cat some kicking. I just hope our doughty devs don't suffer too much irritation from all the chafing on a solved issue. Erik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Wed, 2018-11-21 at 12:17 +, Roger Leigh wrote: > Hi folks, > > I've been following the discussion with interest. It's certainly not a > new discussion, since I remember debating it a good few years back, but > there are still the same opinions and thoughts on the topic that I > remember from back then. > > Some general points to consider: > > 1) A separate /usr serves no practical purpose on a Debian/Devuan system > > With those points considered, merging / and /usr would make sense. > Though equally, keeping the separation doesn't hurt *if they are on the > same filesystem*. If they are to be merged, then there are two > possibilities: moving /usr to / or the contents of /* to /usr. A historical note: The GNU/Hurd people tried to do the merge the other (and right) way around: Moving the contents of /usr to / and creating symlinks. But being small and not having any big corporation backing them up they were laughed at. Let's bring som history into this discussion. HTH! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 22/11/18 06:50, Alessandro Selli wrote: >> He asked 'Why would anybody hardcode the link', what has this to do with >> a shebang ? > > > A shebang is an often used construct that would be broken were not a > link in place. False: Using the shebang "#! /usr/bin/env will work provide the command is in a dir listed in the $PATH -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
> > Maintaining the option of choosing between the two is what Devuan is > trying to do, knowing that it might become harder to support it as > time passes. My guess is that there is no real reason for the basic > system (the stuff needed at boot time before you get to the point > where other filesystems are mounted) to be heavily affected by such a > change, since packagers are not going to hardcode /usr/bin/sh in their > scripts from tomorrow. To be honest I don't even think the option should be presented at install time - certainly not in the way it's currently being presented in the installer - adding yet another dialogue. I suggest we add it as option in the package-selection to install usrmerge or drop it altogether. People that care can install usrmerge at any time post-installation and deal with the consequences. (At the rate we're going, we're adding a new dialogue in the installer per release... soon it will become more tedious to install Devuan then installing windows...) Where upstream does stupid things the way to respond is to patch submit a bug report with a patch to Debian to fix it citing policy (FHS applies here), and also submit patches directly upstream requesting they don't do things that break conformance by hard coding paths to the wrong locations unnecessarily. And if Debian maintainers fail to accept patches, then we can look to a solution in Devuan - either by forking the package or by setting up diversions and/or symlinks to resolve the issue. Cheers, Daniel -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Wed, Nov 21, 2018 at 05:24:24PM +0100, Alessandro Selli wrote: > On 21/11/18 at 16:59, KatolaZ wrote: > > On Wed, Nov 21, 2018 at 07:32:22AM -0800, Rick Moen wrote: > >> Quoting Roger Leigh (rle...@codelibre.net): > >> > >>> I've been following the discussion with interest. > >> For values of 'following' that equates to noting that the matter has > >> been discussed, but then ignoring its substance. > >> > > Dear Rick, > > > > you could have noticed that in essence Roger pointed to the merged-usr > > solution as not only impractical, but also risky and of doubtful > > usefulness. > > > So, you agree then that: > ... ... > 3. "you can't split the package database between separate systems" > (whatever this means, who needs to split the package database and why?); This is about upgrades using the package manager. If there are two /'s sharing one single /usr, when you upgrade, one of the /'s will be upgraded consonant with the /usr, and the other will not be. How then to upgrade the other /? Its package database will no longer be in sync with its /usr. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, Nov 21, 2018 at 06:04:01PM +, Rowland Penny wrote: [cut] > > > > > Did you read the debian bugreport ? > > > > > > Yes, I did. > > > > Now you, how would you have a #!/bin/Rscript script work without a > > filesystem-level link? > > > > > > I repeat, the problem in the bugreport had nothing to do with a shebang, > it was a a hardcoded variable for sed, this worked until sed was moved > to another directory. The script probably would still have worked if, > instead of hardcoding the sed path, it had used the output from 'which' > or 'type' > It actually wouldn't have worked anyway, because `which` uses PATH, and in PATH /usr/bin normally comes before /bin. The package was built in a non-merged-usr env by the maintainer, and worked fine, then it failed when built in the buildd environment, which had been already migrated to merged-usr. The migration of the builders to merged-usr has apparently been reverted (see an email in debian-devel yesterday). My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, 21 Nov 2018 18:50:42 +0100 Alessandro Selli wrote: > On 21/11/18 at 18:39, Rowland Penny wrote: > > On Wed, 21 Nov 2018 18:25:02 +0100 > > Alessandro Selli wrote: > > > >> On 21/11/18 at 18:15, m712 wrote: > Of course we are, why don't you read before replying? > >>> I can't be sure if you are in jest. > >> > >> Of course I am not. > >> > >> Dr. Nikolaus Klepp asked: > >> > >> > >> From: "Dr. Nikolaus Klepp" > >> To: dng@lists.dyne.org > >> Date: Wed, 21 Nov 2018 17:22:00 +0100 > >> Message-Id: <201811211722.00535.dr.kl...@gmx.at> > >> > >> > >> Why would anybody hardcode the link to sed in the first place? > >> Isn't that what $PATH is all about? > >> > >> > >> > >>And I answered with a case where the absolute placement of the > >> sed executable does matter and cannot be circumvented with a PATH > >> setting or the use of commands like which or command. > >> > >> > >> What is not clear? > >> > >> > >> > > You got the context wrong, or as we say here in the UK, you got the > > wrong end of the stick ;-) > > > > He asked 'Why would anybody hardcode the link', what has this to do > > with a shebang ? > > > A shebang is an often used construct that would be broken were not a > link in place. > > Do you need a drawing to see why? > > > > You are quite correct, you cannot replace a shebang with 'which', > > but then, this was never the problem. > > > Yes, it is. Because shebangs do require a link from /usr/bin > to /bin were files moved from /bin to /usr/bin. > > > > Did you read the debian bugreport ? > > > Yes, I did. > > Now you, how would you have a #!/bin/Rscript script work without a > filesystem-level link? > > I repeat, the problem in the bugreport had nothing to do with a shebang, it was a a hardcoded variable for sed, this worked until sed was moved to another directory. The script probably would still have worked if, instead of hardcoding the sed path, it had used the output from 'which' or 'type' It seems I read the bugreport differently to the way you did, we are never going to agree here, you have your point of view, I have mine, so lets just leave it there ;-) Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 21/11/18 at 18:49, k...@aspodata.se wrote: > Alessandro: >> On 21/11/18 at 17:34, k...@aspodata.se wrote: >>> Alessandro: On 21/11/18 at 14:35, k...@aspodata.se wrote: > Hendrik: > ... >> Wait a moment. Haven't we already done this with /boot? Should we >> perhaps have /boot/sbin, and so forth? > /boot is a viable initrd replacement. No, it is not. An initramfs is needed to perform actions that must be done before the / filesystem can be mounted. /boot does not solve the problem of accessing the local storage before it becomes available. >>> What is the problem you is pointing at ? >>> >>> To boot with an uefi system you need a fat partition available before >>> even the bootloader is loaded, so what is the reason that you cannot >>> use that instead of an initrd ? >> I commented about the idea of using /boot in place of the initramfs, >> not about using the EFI partition for that. >> >> You still cannot (or at least should not) do that due to the fact that >> that partition is reserved to EFI, you should not put foreign files into >> it, and initramfs are normally a Unix filesystem, a vfat fiesystem could >> well not work (would the kernel recognize /init as an executable file, >> for instance?). > You can always mount the fat with umask=000 or with showexec and name > the scripts/programs like .exe/.bat/.com. In an initramfs? Seriously? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 21/11/2018 16:24, Alessandro Selli wrote: > > So, you agree then that: I agree from your point of view for your single specific use case. Generally I totally disagree, I manage a diskless cluster that depends on NFS mounted /usr. It doesn't matter to the cluster nodes that the package manager treats /bin and/usr/bin co-jointly on the file server host. e.g. /bin/mount is not version dependant on /usr Utilities locally under /sbin & /bin are useful on the nodes when something goes pear shaped and /usr is not available. > > 1. A separate /usr serves no practical purpose on a Debian/Devuan system; > 2. sharing /usr over NFS "is not practical" (no matter it's been done > for decades); > 3. "you can't split the package database between separate systems" > (whatever this means, who needs to split the package database and why?); > 4. having / and /usr constitute a "managed whole" is the only sensible > way to go; > 5. "there is no practical purpose to the separation as in (1) above"; > 6. "the separate filesystems can be treated as a managed collection. > It's still pointless though"; > 7. following another path other that the systemd/Free(lol!)desktop and > Debian one "It's simply impractical"? > > > Please let me know, because the answer would have deep practical > effects to me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 21/11/18 at 18:39, Rowland Penny wrote: > On Wed, 21 Nov 2018 18:25:02 +0100 > Alessandro Selli wrote: > >> On 21/11/18 at 18:15, m712 wrote: Of course we are, why don't you read before replying? >>> I can't be sure if you are in jest. >> >> Of course I am not. >> >> Dr. Nikolaus Klepp asked: >> >> >> From: "Dr. Nikolaus Klepp" >> To: dng@lists.dyne.org >> Date: Wed, 21 Nov 2018 17:22:00 +0100 >> Message-Id: <201811211722.00535.dr.kl...@gmx.at> >> >> >> Why would anybody hardcode the link to sed in the first place? Isn't >> that what $PATH is all about? >> >> >> >>And I answered with a case where the absolute placement of the sed >> executable does matter and cannot be circumvented with a PATH setting >> or the use of commands like which or command. >> >> >> What is not clear? >> >> >> > You got the context wrong, or as we say here in the UK, you got the > wrong end of the stick ;-) > > He asked 'Why would anybody hardcode the link', what has this to do with > a shebang ? A shebang is an often used construct that would be broken were not a link in place. Do you need a drawing to see why? > You are quite correct, you cannot replace a shebang with 'which', but > then, this was never the problem. Yes, it is. Because shebangs do require a link from /usr/bin to /bin were files moved from /bin to /usr/bin. > Did you read the debian bugreport ? Yes, I did. Now you, how would you have a #!/bin/Rscript script work without a filesystem-level link? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Alessandro: > On 21/11/18 at 17:34, k...@aspodata.se wrote: > > Alessandro: > >> On 21/11/18 at 14:35, k...@aspodata.se wrote: > >>> Hendrik: > >>> ... > Wait a moment. Haven't we already done this with /boot? Should we > perhaps have /boot/sbin, and so forth? > >>> /boot is a viable initrd replacement. > >> > >> No, it is not. An initramfs is needed to perform actions that must be > >> done before the / filesystem can be mounted. /boot does not solve the > >> problem of accessing the local storage before it becomes available. > > What is the problem you is pointing at ? > > > > To boot with an uefi system you need a fat partition available before > > even the bootloader is loaded, so what is the reason that you cannot > > use that instead of an initrd ? > > I commented about the idea of using /boot in place of the initramfs, > not about using the EFI partition for that. > > You still cannot (or at least should not) do that due to the fact that > that partition is reserved to EFI, you should not put foreign files into > it, and initramfs are normally a Unix filesystem, a vfat fiesystem could > well not work (would the kernel recognize /init as an executable file, > for instance?). You can always mount the fat with umask=000 or with showexec and name the scripts/programs like .exe/.bat/.com. I haven't tested using the fat for /boot, but you still have the disk available. Adding a /boot partition isn't a biggie if the fat partition doesn't work, or for the matter any other kind of partition, the disk is available, and you have prooved it by loading the boot loader. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, 21 Nov 2018 18:29:59 +0100 Alessandro Selli wrote: > On 21/11/18 at 18:21, Rowland Penny wrote: > > On Wed, 21 Nov 2018 18:05:44 +0100 > > Alessandro Selli wrote: > > > >> On 21/11/18 at 17:57, Rowland Penny wrote: > >>> On Wed, 21 Nov 2018 17:43:12 +0100 > >>> Alessandro Selli wrote: > >>> > On 21/11/18 at 17:37, Rowland Penny wrote: > > On Wed, 21 Nov 2018 17:28:40 +0100 > > Alessandro Selli wrote: > > > >> On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: > >>> Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: > >> [...] > >> > >> > I read the discussion at > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html > and it looks as if they fixed the discrepancy at version > 3.5.1-2. Which means if we want to keep sed in /bin instead > of /usr/bin we may have to patch both packages sed and > r-base. > > Or maybe add a symblic link to make sed accessible > from /usr/bin instead of just /bin. > >>> Why would anybody hardcode the link to sed in the first place? > >>> Isn't that what $PATH is all about? > >> It's necessary to keep script shebangs from breaking. > >> > > No it isn't, ever heard of 'which' or 'type' or checking if the > > file actually exists. > > > > Rowland > > > Of course it is. If you have a file with a shebang like this: > > > #!/bin/sed > > , which is the norm, see: > > https://github.com/uuner/sedtris/blob/master/sedtris.sed > > , then you'd be in trouble if sed moved in /usr/bin. > >>> Well it would if you were trying to run sed directly, > >> > >> Which side of "sed script with a shebang" do you fail to grasp? > > And which part of 'that isn't the problem' do you fail to grasp ? > > > You asked: > > > From: "Dr. Nikolaus Klepp" > To: dng@lists.dyne.org > Date: Wed, 21 Nov 2018 17:22:00 +0100 > Message-Id: <201811211722.00535.dr.kl...@gmx.at> > > > "Why would anybody hardcode the link to sed in the first place? Isn't > that what $PATH is all about?" > > > I answered to this question. > > > > From the debian bug report: > > > I did not answer any question about Debian bug reports, I answered > to the afore-quoted question. > > The Debian bug report is related anyway, because (though you didn't > know it) R itself can and in fact is used as a scripting language. > 'R' itself is a bash script and it hard codes the path to sed in it, this is, IMO, a stupid idea and lead to the problem when sed was moved. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, Nov 21, 2018 at 08:15:59PM +0300, m712 wrote: [cut] > >>> > >>> #!/bin/sed > >>> > >>> , which is the norm, see: > >>> > >>> https://github.com/uuner/sedtris/blob/master/sedtris.sed > >>> > >>> , then you'd be in trouble if sed moved in /usr/bin. > >> Well it would if you were trying to run sed directly, > > > > > > Which side of "sed script with a shebang" do you fail to grasp? > This thread is about Debian breaking R. If you want to talk about she-bangs, > make your own. /usr/bin/env is also a thing that is pretty standard on Linux > distros. Actually, this part of the thread is mostly about nothing at all, since the bug revelead by the R package has been apparently solved (it was due to deboostrap defaulting to merged-user in their configs, and the change has been reverted). We could probably see a couple of concrete problems when (and if) Debian decides to default to merged-usr in the builders. But this will most probably not happen right now (if at all). HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Wed, Nov 21, 2018 at 05:24:24PM +0100, Alessandro Selli wrote: > On 21/11/18 at 16:59, KatolaZ wrote: > > On Wed, Nov 21, 2018 at 07:32:22AM -0800, Rick Moen wrote: > >> Quoting Roger Leigh (rle...@codelibre.net): > >> > >>> I've been following the discussion with interest. > >> For values of 'following' that equates to noting that the matter has > >> been discussed, but then ignoring its substance. > >> > > Dear Rick, > > > > you could have noticed that in essence Roger pointed to the merged-usr > > solution as not only impractical, but also risky and of doubtful > > usefulness. > > > So, you agree then that: > > > 1. A separate /usr serves no practical purpose on a Debian/Devuan system; I don't think this is true or false. It just depends on the specific cases. > 2. sharing /usr over NFS "is not practical" (no matter it's been done > for decades); Again, neither true or false, depends on the applications. It is defintely practical in some cases, totally useless in other cases. > 3. "you can't split the package database between separate systems" > (whatever this means, who needs to split the package database and why?); > 4. having / and /usr constitute a "managed whole" is the only sensible > way to go; I don't see where Roger said that in his email. > 5. "there is no practical purpose to the separation as in (1) above"; Having /usr as a copy of / is not something that any unix-like system has done forever, or anything that belongs to "ye auld unix tradition" for a solid reason (yeah I know, diskless workstations, but those are not any more "the common way" a unix-like system is used, since at least 15 or 20 years ago. The other reason was space constraints, and this is not a solid reason any more...). The KISS approach would be to keep all the binaries in the / filesystem (this was actually what V7 did). In a sense, the merge should have been probably done the other way round, if at all. > 6. "the separate filesystems can be treated as a managed collection. > It's still pointless though"; > 7. following another path other that the systemd/Free(lol!)desktop and > Debian one "It's simply impractical"? > He said quite the opposite. He said that it is impractical to manage a transition from a non-merged-usr to a merged-usr system, since the odds are high that something can go wrong. > > Please let me know, because the answer would have deep practical > effects to me. > This is totally inconsequential. I personally think that the move to merged-usr is just useless and I can't see a proper reason for that to happen. But I don't see any good technical reason to forbid it completely. Hence, I think that allowing the user to choose is the best way through. Maintaining the option of choosing between the two is what Devuan is trying to do, knowing that it might become harder to support it as time passes. My guess is that there is no real reason for the basic system (the stuff needed at boot time before you get to the point where other filesystems are mounted) to be heavily affected by such a change, since packagers are not going to hardcode /usr/bin/sh in their scripts from tomorrow. On average, nothing that anybody else can say or do could have deep practical effects on me, and I strive to make sure that nothing that I say or do has any practical bad effect on anybody else. I am convinced that the world would be a slightly better place if we all tried a bit of that thinking ;) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, 21 Nov 2018 18:25:02 +0100 Alessandro Selli wrote: > On 21/11/18 at 18:15, m712 wrote: > >> Of course we are, why don't you read before replying? > > I can't be sure if you are in jest. > > > Of course I am not. > > Dr. Nikolaus Klepp asked: > > > From: "Dr. Nikolaus Klepp" > To: dng@lists.dyne.org > Date: Wed, 21 Nov 2018 17:22:00 +0100 > Message-Id: <201811211722.00535.dr.kl...@gmx.at> > > > Why would anybody hardcode the link to sed in the first place? Isn't > that what $PATH is all about? > > > >And I answered with a case where the absolute placement of the sed > executable does matter and cannot be circumvented with a PATH setting > or the use of commands like which or command. > > > What is not clear? > > > You got the context wrong, or as we say here in the UK, you got the wrong end of the stick ;-) He asked 'Why would anybody hardcode the link', what has this to do with a shebang ? You are quite correct, you cannot replace a shebang with 'which', but then, this was never the problem. Did you read the debian bugreport ? Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 21/11/18 at 18:21, Rowland Penny wrote: > On Wed, 21 Nov 2018 18:05:44 +0100 > Alessandro Selli wrote: > >> On 21/11/18 at 17:57, Rowland Penny wrote: >>> On Wed, 21 Nov 2018 17:43:12 +0100 >>> Alessandro Selli wrote: >>> On 21/11/18 at 17:37, Rowland Penny wrote: > On Wed, 21 Nov 2018 17:28:40 +0100 > Alessandro Selli wrote: > >> On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: >>> Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: >> [...] >> >> I read the discussion at https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html and it looks as if they fixed the discrepancy at version 3.5.1-2. Which means if we want to keep sed in /bin instead of /usr/bin we may have to patch both packages sed and r-base. Or maybe add a symblic link to make sed accessible from /usr/bin instead of just /bin. >>> Why would anybody hardcode the link to sed in the first place? >>> Isn't that what $PATH is all about? >> It's necessary to keep script shebangs from breaking. >> > No it isn't, ever heard of 'which' or 'type' or checking if the > file actually exists. > > Rowland > Of course it is. If you have a file with a shebang like this: #!/bin/sed , which is the norm, see: https://github.com/uuner/sedtris/blob/master/sedtris.sed , then you'd be in trouble if sed moved in /usr/bin. >>> Well it would if you were trying to run sed directly, >> >> Which side of "sed script with a shebang" do you fail to grasp? > And which part of 'that isn't the problem' do you fail to grasp ? You asked: From: "Dr. Nikolaus Klepp" To: dng@lists.dyne.org Date: Wed, 21 Nov 2018 17:22:00 +0100 Message-Id: <201811211722.00535.dr.kl...@gmx.at> "Why would anybody hardcode the link to sed in the first place? Isn't that what $PATH is all about?" I answered to this question. > From the debian bug report: I did not answer any question about Debian bug reports, I answered to the afore-quoted question. The Debian bug report is related anyway, because (though you didn't know it) R itself can and in fact is used as a scripting language. See here, for an example: https://stackoverflow.com/questions/3128122/shebang-line-not-working-in-r-script -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 21/11/18 at 18:15, m712 wrote: >> Of course we are, why don't you read before replying? > I can't be sure if you are in jest. Of course I am not. Dr. Nikolaus Klepp asked: From: "Dr. Nikolaus Klepp" To: dng@lists.dyne.org Date: Wed, 21 Nov 2018 17:22:00 +0100 Message-Id: <201811211722.00535.dr.kl...@gmx.at> Why would anybody hardcode the link to sed in the first place? Isn't that what $PATH is all about? And I answered with a case where the absolute placement of the sed executable does matter and cannot be circumvented with a PATH setting or the use of commands like which or command. What is not clear? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, 21 Nov 2018 18:05:44 +0100 Alessandro Selli wrote: > On 21/11/18 at 17:57, Rowland Penny wrote: > > On Wed, 21 Nov 2018 17:43:12 +0100 > > Alessandro Selli wrote: > > > >> On 21/11/18 at 17:37, Rowland Penny wrote: > >>> On Wed, 21 Nov 2018 17:28:40 +0100 > >>> Alessandro Selli wrote: > >>> > On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: > > Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: > [...] > > > >> I read the discussion at > >> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html > >> and it looks as if they fixed the discrepancy at version > >> 3.5.1-2. Which means if we want to keep sed in /bin instead > >> of /usr/bin we may have to patch both packages sed and r-base. > >> > >> Or maybe add a symblic link to make sed accessible > >> from /usr/bin instead of just /bin. > > Why would anybody hardcode the link to sed in the first place? > > Isn't that what $PATH is all about? > It's necessary to keep script shebangs from breaking. > > >>> No it isn't, ever heard of 'which' or 'type' or checking if the > >>> file actually exists. > >>> > >>> Rowland > >>> > >> Of course it is. If you have a file with a shebang like this: > >> > >> > >> #!/bin/sed > >> > >> , which is the norm, see: > >> > >> https://github.com/uuner/sedtris/blob/master/sedtris.sed > >> > >> , then you'd be in trouble if sed moved in /usr/bin. > > Well it would if you were trying to run sed directly, > > > Which side of "sed script with a shebang" do you fail to grasp? And which part of 'that isn't the problem' do you fail to grasp ? From the debian bug report: The problem appears to be on line 122 of /usr/lib/R/bin/R and /usr/bin/R, where between r-base-core 3.5.1-1+b1 and 3.5.1-1+b2, SED=/bin/sed changed to SED=/usr/bin/sed The script sets the path to sed with a hard coded path instead of finding out where sed actually is. Either don't set the variable and use $PATH to find it, or use something to find sed, then use this to set the variable. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Roger Leigh - 21.11.18, 13:17: > Lastly, regarding the comments about Devuan "disenfranchising" itself > from Debian to not be "in the back seat". I take the point, but the > practical reality is that Debian is so huge not even a company with > many dozens of employees like Canonical could manage that feat. It's > simply impractical. If Devuan continues as a derivative by > maintaining a modified set of core packages to meet specific goals, > it would seem that it's meeting it's core objectives, and that's no > bad thing. It's realistic, and manageable. The aim for Debian Buster is to have new installation with usr merged. I did not read of plans to migrate existing installations during upgrade. But there is still a discussion whether going for merged usr so shortly before release freeze actually really makes sense. See mailing list debian-devel. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On November 21, 2018 8:05:44 PM GMT+03:00, Alessandro Selli wrote: >On 21/11/18 at 17:57, Rowland Penny wrote: >> On Wed, 21 Nov 2018 17:43:12 +0100 >> Alessandro Selli wrote: >> >>> On 21/11/18 at 17:37, Rowland Penny wrote: On Wed, 21 Nov 2018 17:28:40 +0100 Alessandro Selli wrote: > On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: >> Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: > [...] > > >>> I read the discussion at >>> >https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html >>> and it looks as if they fixed the discrepancy at version >3.5.1-2. >>> Which means if we want to keep sed in /bin instead of /usr/bin >we >>> may have to patch both packages sed and r-base. >>> >>> Or maybe add a symblic link to make sed accessible from /usr/bin >>> instead of just /bin. >> Why would anybody hardcode the link to sed in the first place? >> Isn't that what $PATH is all about? > It's necessary to keep script shebangs from breaking. > No it isn't, ever heard of 'which' or 'type' or checking if the >file actually exists. Rowland >>> Of course it is. If you have a file with a shebang like this: >>> >>> >>> #!/bin/sed >>> >>> , which is the norm, see: >>> >>> https://github.com/uuner/sedtris/blob/master/sedtris.sed >>> >>> , then you'd be in trouble if sed moved in /usr/bin. >> Well it would if you were trying to run sed directly, > > > Which side of "sed script with a shebang" do you fail to grasp? This thread is about Debian breaking R. If you want to talk about she-bangs, make your own. /usr/bin/env is also a thing that is pretty standard on Linux distros. > >> but in this case >> it is setting the path to sed as a variable, so, if the script >> '/usr/bin/R' used something like this: >> >> SED="$(which sed)" >> if [ -z "$SED" ]; then >> echo 'sed is not installed' >> exit 1 >> fi >> export SED >> >> instead of: >> SED=/bin/sed >> export SED > > > Try putting this in place of a sed shebang and see what happens to >your sed script. The discussion wasn't about a shell script before you interjected. > >> We wouldn't be having this conversation. > > >... if you were any knowledgeable about shell scripting. Are you trying to have some sort of pissing match? > >>> >>> Of course you know you can't use commands or shell constructs in >>> place of the shebang, you did shell_scripting-101, didn't you? >>> >> We are not talking about the shebang, you did know that, didn't you ? > > > Of course we are, why don't you read before replying? I can't be sure if you are in jest. m712 -- https://nextchan.org -- https://gitgud.io/blazechan/blazechan I am awake between 3AM-8PM UTC, HMU if the site's broken ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 21/11/18 at 17:57, Rowland Penny wrote: > On Wed, 21 Nov 2018 17:43:12 +0100 > Alessandro Selli wrote: > >> On 21/11/18 at 17:37, Rowland Penny wrote: >>> On Wed, 21 Nov 2018 17:28:40 +0100 >>> Alessandro Selli wrote: >>> On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: > Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: [...] >> I read the discussion at >> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html >> and it looks as if they fixed the discrepancy at version 3.5.1-2. >> Which means if we want to keep sed in /bin instead of /usr/bin we >> may have to patch both packages sed and r-base. >> >> Or maybe add a symblic link to make sed accessible from /usr/bin >> instead of just /bin. > Why would anybody hardcode the link to sed in the first place? > Isn't that what $PATH is all about? It's necessary to keep script shebangs from breaking. >>> No it isn't, ever heard of 'which' or 'type' or checking if the file >>> actually exists. >>> >>> Rowland >>> >> Of course it is. If you have a file with a shebang like this: >> >> >> #!/bin/sed >> >> , which is the norm, see: >> >> https://github.com/uuner/sedtris/blob/master/sedtris.sed >> >> , then you'd be in trouble if sed moved in /usr/bin. > Well it would if you were trying to run sed directly, Which side of "sed script with a shebang" do you fail to grasp? > but in this case > it is setting the path to sed as a variable, so, if the script > '/usr/bin/R' used something like this: > > SED="$(which sed)" > if [ -z "$SED" ]; then > echo 'sed is not installed' > exit 1 > fi > export SED > > instead of: > SED=/bin/sed > export SED Try putting this in place of a sed shebang and see what happens to your sed script. > We wouldn't be having this conversation. ... if you were any knowledgeable about shell scripting. >> >> Of course you know you can't use commands or shell constructs in >> place of the shebang, you did shell_scripting-101, didn't you? >> > We are not talking about the shebang, you did know that, didn't you ? Of course we are, why don't you read before replying? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, 21 Nov 2018 17:43:12 +0100 Alessandro Selli wrote: > On 21/11/18 at 17:37, Rowland Penny wrote: > > On Wed, 21 Nov 2018 17:28:40 +0100 > > Alessandro Selli wrote: > > > >> On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: > >>> Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: > >> > >> [...] > >> > >> > I read the discussion at > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html > and it looks as if they fixed the discrepancy at version 3.5.1-2. > Which means if we want to keep sed in /bin instead of /usr/bin we > may have to patch both packages sed and r-base. > > Or maybe add a symblic link to make sed accessible from /usr/bin > instead of just /bin. > >>> Why would anybody hardcode the link to sed in the first place? > >>> Isn't that what $PATH is all about? > >> > >> It's necessary to keep script shebangs from breaking. > >> > > No it isn't, ever heard of 'which' or 'type' or checking if the file > > actually exists. > > > > Rowland > > > > Of course it is. If you have a file with a shebang like this: > > > #!/bin/sed > > , which is the norm, see: > > https://github.com/uuner/sedtris/blob/master/sedtris.sed > > , then you'd be in trouble if sed moved in /usr/bin. Well it would if you were trying to run sed directly, but in this case it is setting the path to sed as a variable, so, if the script '/usr/bin/R' used something like this: SED="$(which sed)" if [ -z "$SED" ]; then echo 'sed is not installed' exit 1 fi export SED instead of: SED=/bin/sed export SED We wouldn't be having this conversation. > > > Of course you know you can't use commands or shell constructs in > place of the shebang, you did shell_scripting-101, didn't you? > We are not talking about the shebang, you did know that, didn't you ? Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 21/11/18 at 17:34, k...@aspodata.se wrote: > Alessandro: >> On 21/11/18 at 14:35, k...@aspodata.se wrote: >>> Hendrik: >>> ... Wait a moment. Haven't we already done this with /boot? Should we perhaps have /boot/sbin, and so forth? >>> /boot is a viable initrd replacement. >> >> No, it is not. An initramfs is needed to perform actions that must be >> done before the / filesystem can be mounted. /boot does not solve the >> problem of accessing the local storage before it becomes available. > What is the problem you is pointing at ? > > To boot with an uefi system you need a fat partition available before > even the bootloader is loaded, so what is the reason that you cannot > use that instead of an initrd ? I commented about the idea of using /boot in place of the initramfs, not about using the EFI partition for that. You still cannot (or at least should not) do that due to the fact that that partition is reserved to EFI, you should not put foreign files into it, and initramfs are normally a Unix filesystem, a vfat fiesystem could well not work (would the kernel recognize /init as an executable file, for instance?). -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 21/11/18 at 17:37, Rowland Penny wrote: > On Wed, 21 Nov 2018 17:28:40 +0100 > Alessandro Selli wrote: > >> On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: >>> Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: >> >> [...] >> >> I read the discussion at https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html and it looks as if they fixed the discrepancy at version 3.5.1-2. Which means if we want to keep sed in /bin instead of /usr/bin we may have to patch both packages sed and r-base. Or maybe add a symblic link to make sed accessible from /usr/bin instead of just /bin. >>> Why would anybody hardcode the link to sed in the first place? >>> Isn't that what $PATH is all about? >> >> It's necessary to keep script shebangs from breaking. >> > No it isn't, ever heard of 'which' or 'type' or checking if the file > actually exists. > > Rowland > Of course it is. If you have a file with a shebang like this: #!/bin/sed , which is the norm, see: https://github.com/uuner/sedtris/blob/master/sedtris.sed , then you'd be in trouble if sed moved in /usr/bin. Of course you know you can't use commands or shell constructs in place of the shebang, you did shell_scripting-101, didn't you? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Quoting KatolaZ (kato...@freaknet.org): > you could have noticed that in essence Roger pointed to the merged-usr > solution as not only impractical, but also risky and of doubtful > usefulness. Noted without comment: Modern disk sizes make partitioning a separate /usr unnecessary and undesirable. (Both are of course /possible/, but there is precious little to gain by doing so.) Oh, on reconsideration, I'll comment (on that snippet as representative of the whole), but will then wish to move on. I posted upthread a real-world example of a server partitioning scheme that used separate /usr to good effect on multiple grounds, including (1) grouping filesystems for minimum average HD seeks, (2) distinct mount options per filesystem (e.g., nodev and read-only for /usr) to reduce potential for adminstrative and software mishap, and (3) bespoke filesystem options to eliminate unjustiable overhead (e.g., no journaling on /usr, in light of it normally being mounted read-only). It's vexing to be told that server best practices are unnecessary, undesirable, and gain little (and other places as 'not really doing more than adding extra unnecessary complexity' and that 'none of it actually matters') by someone who seems not to have grasped the issues. But I didn't volunteer to argue. The whole extremely long and tendentious piece is... marbled with such things, and I really have better things to do than to spend an hour dissecting such material. I'd rather say 'Have a great day' and move on. > It seems to go in pretty much the same direction as you, > with a technical and thorough explanation around :) It seems to me that: No and no. Oh well. You have a great day, as well. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Wed, 21 Nov 2018 17:28:40 +0100 Alessandro Selli wrote: > On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: > > Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: > > > [...] > > > >> I read the discussion at > >> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html > >> and it looks as if they fixed the discrepancy at version 3.5.1-2. > >> Which means if we want to keep sed in /bin instead of /usr/bin we > >> may have to patch both packages sed and r-base. > >> > >> Or maybe add a symblic link to make sed accessible from /usr/bin > >> instead of just /bin. > > Why would anybody hardcode the link to sed in the first place? > > Isn't that what $PATH is all about? > > > It's necessary to keep script shebangs from breaking. > No it isn't, ever heard of 'which' or 'type' or checking if the file actually exists. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Alessandro: > On 21/11/18 at 14:35, k...@aspodata.se wrote: > > Hendrik: > > ... > >> Wait a moment. Haven't we already done this with /boot? Should we > >> perhaps have /boot/sbin, and so forth? > > /boot is a viable initrd replacement. > > > No, it is not. An initramfs is needed to perform actions that must be > done before the / filesystem can be mounted. /boot does not solve the > problem of accessing the local storage before it becomes available. What is the problem you is pointing at ? To boot with an uefi system you need a fat partition available before even the bootloader is loaded, so what is the reason that you cannot use that instead of an initrd ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On 21/11/18 at 17:22, Dr. Nikolaus Klepp wrote: > Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: [...] >> I read the discussion at >> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html >> and it looks as if they fixed the discrepancy at version 3.5.1-2. >> Which means if we want to keep sed in /bin instead of /usr/bin we may >> have to patch both packages sed and r-base. >> >> Or maybe add a symblic link to make sed accessible from /usr/bin instead >> of just /bin. > Why would anybody hardcode the link to sed in the first place? Isn't that > what $PATH is all about? It's necessary to keep script shebangs from breaking. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 21/11/18 at 16:59, KatolaZ wrote: > On Wed, Nov 21, 2018 at 07:32:22AM -0800, Rick Moen wrote: >> Quoting Roger Leigh (rle...@codelibre.net): >> >>> I've been following the discussion with interest. >> For values of 'following' that equates to noting that the matter has >> been discussed, but then ignoring its substance. >> > Dear Rick, > > you could have noticed that in essence Roger pointed to the merged-usr > solution as not only impractical, but also risky and of doubtful > usefulness. So, you agree then that: 1. A separate /usr serves no practical purpose on a Debian/Devuan system; 2. sharing /usr over NFS "is not practical" (no matter it's been done for decades); 3. "you can't split the package database between separate systems" (whatever this means, who needs to split the package database and why?); 4. having / and /usr constitute a "managed whole" is the only sensible way to go; 5. "there is no practical purpose to the separation as in (1) above"; 6. "the separate filesystems can be treated as a managed collection. It's still pointless though"; 7. following another path other that the systemd/Free(lol!)desktop and Debian one "It's simply impractical"? Please let me know, because the answer would have deep practical effects to me. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
Am Mittwoch, 21. November 2018 schrieb Hendrik Boom: > On Mon, Nov 19, 2018 at 05:19:03PM +0100, Enrico Weigelt, metux IT consult > wrote: > > > > just for your amusement ... > > > > > > Forwarded Message > > Subject: Our build system may be broken: /bin vs /usr/bin > > Resent-Date: Mon, 19 Nov 2018 15:01:46 + (UTC) > > Resent-From: debian-de...@lists.debian.org > > Date: Mon, 19 Nov 2018 08:55:31 -0600 > > From: Dirk Eddelbuettel > > To: Debian Developers > > CC: Dirk Eddelbuettel > > > > > > > > tl;dr: We may be messing up /bin and /usr/bin on some platforms > > They have already started making busy-work for us. > > > > > > > Sorry for the alarming headline but #913982 was filed, indepedently > > corrobated and simultaneously discovered by upstream. > > > > GNU R has long been relying on sed, tar, bzip2, ... and many more base > > tools. No issues there. Generally looked for in /bin and found there. > > > > Starting with binary rebuild r-base_3.5.1-1+b2 however, /usr/bin/* path > > crept > > in while the binaries where still in the wrong place. It looked like a > > one-off so I uploaded 3.5.1-2 which built fine for me on amd64 ...but > > apparently is already borked again on i386. > > I read the discussion at > https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html > and it looks as if they fixed the discrepancy at version 3.5.1-2. > Which means if we want to keep sed in /bin instead of /usr/bin we may > have to patch both packages sed and r-base. > > Or maybe add a symblic link to make sed accessible from /usr/bin instead > of just /bin. Why would anybody hardcode the link to sed in the first place? Isn't that what $PATH is all about? Nik > > -- hendrik > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On 21/11/18 at 13:17, Roger Leigh wrote: > Hi folks, > > I've been following the discussion with interest. No, you definitely have not followed it. In fact you are disregarding all the points that were expressed against the merge. > It's certainly not a new discussion, since I remember debating it a > good few years back, but there are still the same opinions and > thoughts on the topic that I remember from back then. > > Some general points to consider: > > 1) A separate /usr serves no practical purpose on a Debian/Devuan system Yes it does, and they were already listed: 1) mounting /usr with different mount options (like barrier, ro, nodev etc); 2) having /usr mounted over the network keeping / local; 3) having a /usr partition shared by several local installs that are booted on different / filesystems; 4) having the smallest possible / filesystem to ease recovery of a botched system. > Historically, /usr was separately mountable, shareable over NFS. > With a package manager like dpkg, / and /usr are an integrated, > managed whole. Sharing over NFS is not practical since the managed > files span both parts, and you can't split the package database > between separate systems. Modern disk sizes make partitioning a > separate /usr unnecessary and undesirable. (Both are of course > /possible/, but there is precious little to gain by doing so.) This too was debated and rejected. It doesn't matter if some idea originated out of specific restraints or circumstances, of it it was a bad idea at the time. Time proved it to be a good filesystem layout, and it's for this reason is has survived to this day. > Other systems, like the BSDs, have the effective split between base > (/) and ports (/usr/local). / and /usr are still effectively a > managed whole containing the "base system". So what? How does this imply that the possibility of not having a "managed whole" in Linux is a bad idea? > With those points considered, merging / and /usr would make sense. Being those points baseless, the proposed merge lacks the sense it needs to be forced upon everybody. > Though equally, keeping the separation doesn't hurt *if they are on > the same filesystem*. Most of the times the separation is needed just to have / and /usr stay on different filesystems. The merge would make this impossible. > If they are to be merged, then there are two possibilities: moving > /usr to / or the contents of /* to /usr. > > The point about /usr being a good place for "static" content is a > reasonable one. But for better or worse, / is "the system". It's > still part of the managed whole, Please keep this misplaced worship of your sacred "managed whole" away from *my* systems. Splitters are nor forcing they choices on others and their operations do not adversely affect the possibility of merging whatever one wants. Mergers instead are keen at imposing their baseless sense of technical perfection on everybody reducing the effective freedom of system customization. > and hiving off a static /usr rather than hiving off the variable > changing content isn't really doing more than adding extra unnecessary > complexity. "Unecessary" according to whom? Once merged, several operations that were possible with a split /usr are no longer possible, how is that a simplification? You are basically stating that having people stop customizing key aspects of their OS layout and organization to force everybody into the same mold is good because it simplifies matters. What would it simplify and to whom? Taking freedom away can be regarded as a form of simplification, I agree, but it's a sick simplification, like banning all left-handed people out of society. > 2) Moving the content to /usr doesn't preclude moving it to / later And keeping / splittable from /usr does not prevent anybody from merging them, too. > RedHat/systemd have decided to move everything to /usr, and Debian > have decided to copy this as they have for most systemd-dictated > changes. I'd prefer it to be the other way around; it's cleaner [lots of drivel trashed] > Lastly, regarding the comments about Devuan "disenfranchising" itself > from Debian to not be "in the back seat". I take the point, but the > practical reality is that Debian is so huge not even a company with > many dozens of employees like Canonical could manage that feat. It's > simply impractical. If Devuan continues as a derivative by > maintaining a modified set of core packages to meet specific goals, it > would seem that it's meeting it's core objectives, and that's no bad > thing. It's realistic, and manageable. The fact that Canonical decided to keep following Debian's architectural design is pointless. AFAIK this decision did not stem out of the consideration that Canonical was unable to go it's own way, in fact it did several times (even though with no much success, like when they produced Ubuntu Touch aka Ubunt
Re: [DNG] /usr to merge or not to merge... that is the question
On Wed, Nov 21, 2018 at 07:32:22AM -0800, Rick Moen wrote: > Quoting Roger Leigh (rle...@codelibre.net): > > > I've been following the discussion with interest. > > For values of 'following' that equates to noting that the matter has > been discussed, but then ignoring its substance. > Dear Rick, you could have noticed that in essence Roger pointed to the merged-usr solution as not only impractical, but also risky and of doubtful usefulness. It seems to go in pretty much the same direction as you, with a technical and thorough explanation around :) My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Quoting Roger Leigh (rle...@codelibre.net): > I've been following the discussion with interest. For values of 'following' that equates to noting that the matter has been discussed, but then ignoring its substance. OK, great. Have an enjoyable day. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On 21/11/18 at 14:35, k...@aspodata.se wrote: > Hendrik: > ... >> Wait a moment. Haven't we already done this with /boot? Should we >> perhaps have /boot/sbin, and so forth? > /boot is a viable initrd replacement. No, it is not. An initramfs is needed to perform actions that must be done before the / filesystem can be mounted. /boot does not solve the problem of accessing the local storage before it becomes available. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Wed, Nov 21, 2018 at 12:17:21PM +, Roger Leigh wrote: > Hi folks, > > I've been following the discussion with interest. It's certainly not a new > discussion, since I remember debating it a good few years back, but there > are still the same opinions and thoughts on the topic that I remember from > back then. > > Some general points to consider: > > 1) A separate /usr serves no practical purpose on a Debian/Devuan system > >Historically, /usr was separately mountable, shareable over NFS. With a > package manager like dpkg, / and /usr are an integrated, managed whole. > Sharing over NFS is not practical since the managed files span both parts, > and you can't split the package database between separate systems. Modern > disk sizes make partitioning a separate /usr unnecessary and undesirable. > (Both are of course /possible/, but there is precious little to gain by > doing so.) > >Other systems, like the BSDs, have the effective split between base (/) > and ports (/usr/local). / and /usr are still effectively a managed whole > containing the "base system". > >With those points considered, merging / and /usr would make sense. Though > equally, keeping the separation doesn't hurt *if they are on the same > filesystem*. If they are to be merged, then there are two possibilities: > moving /usr to / or the contents of /* to /usr. > >The point about /usr being a good place for "static" content is a > reasonable one. But for better or worse, / is "the system". It's still > part of the managed whole, and hiving off a static /usr rather than hiving > off the variable changing content isn't really doing more than adding extra > unnecessary complexity. > > 2) Moving the content to /usr doesn't preclude moving it to / later > >RedHat/systemd have decided to move everything to /usr, and Debian have > decided to copy this as they have for most systemd-dictated changes. I'd > prefer it to be the other way around; it's cleaner and it's what we would > choose given a clean slate. However, when multiple filesystems are in use, > /usr is often larger and this is potentially the safer move *for upgrades*. > >dpkg permits any directory in the filesystem hierarchy to be replaced by > a symbolic link. If the contents of /bin, /lib etc. are moved to /usr/bin, > /usr/lib etc., they can be replaced by symlinks so that /bin/sh and > /lib/ld.so and other fixed paths continue to work correctly. > >Conversely, /usr can be symlinked to /. This permits /usr/bin/perl to > continue to work even if the interpreter is in /bin. hendrik@midwinter:~$ ls /usr bin games include lib local lost+found sbin share src hendrik@midwinter:~$ better to symlink /usr/bin to /bin, /usr/games to /games, and so forth. Otherwise recursive file scans can easily end up looping through /, /usr, /usr/usr, /usr/usr/usr, and so forth. -- hendrik ... ... > > Like a lot of systemd-driven changes, unifying these filesystems is > technically possible, slightly desirable, but at a huge practical cost. The > main costs are the severe risks taken to migrate essential system files and > rearrange the root filesystem during an upgrade. Given that from the user's > and sysadmin's point of view, the system behaves the same both before and > after the upgrade, they are being required to undertake a large risk for > *almost zero* practical benefit. Personally, I would argue this should only > be done for fresh installations. I don't think the potential for > near-irreparable damage to running systems is acceptable. Depending upon > the configuration, there's a risk of the system no longer being bootable, of > the system being in a corrupt state if the migration fails due to the /usr > filesystem not having enough space to migrate the files, or dpkg not being > able to revert or complete the operation if interrupted. Better for the /usr to be corrupt than for / to become corrupt. With merely a corrupt /usr, it's still possible to use system recovery tools in / to recover the system. Unless, of course they've all been moved to /usr with symlinks. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] yet another case of silly Lennartism :p [Fwd: Our build system may be broken: /bin vs /usr/bin]
On Mon, Nov 19, 2018 at 05:19:03PM +0100, Enrico Weigelt, metux IT consult wrote: > > just for your amusement ... > > > Forwarded Message > Subject: Our build system may be broken: /bin vs /usr/bin > Resent-Date: Mon, 19 Nov 2018 15:01:46 + (UTC) > Resent-From: debian-de...@lists.debian.org > Date: Mon, 19 Nov 2018 08:55:31 -0600 > From: Dirk Eddelbuettel > To: Debian Developers > CC: Dirk Eddelbuettel > > > > tl;dr: We may be messing up /bin and /usr/bin on some platforms They have already started making busy-work for us. > > > Sorry for the alarming headline but #913982 was filed, indepedently > corrobated and simultaneously discovered by upstream. > > GNU R has long been relying on sed, tar, bzip2, ... and many more base > tools. No issues there. Generally looked for in /bin and found there. > > Starting with binary rebuild r-base_3.5.1-1+b2 however, /usr/bin/* path > crept > in while the binaries where still in the wrong place. It looked like a > one-off so I uploaded 3.5.1-2 which built fine for me on amd64 ...but > apparently is already borked again on i386. I read the discussion at https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1642443.html and it looks as if they fixed the discrepancy at version 3.5.1-2. Which means if we want to keep sed in /bin instead of /usr/bin we may have to patch both packages sed and r-base. Or maybe add a symblic link to make sed accessible from /usr/bin instead of just /bin. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Hendrik:
...
> Wait a moment. Haven't we already done this with /boot? Should we
> perhaps have /boot/sbin, and so forth?
/boot is a viable initrd replacement. The downside is that there is
only one /boot, where you can have one initrd per kernel. But that
could be solved by some script.
I actually have a gentoo system with busybox (from install time) in
/boot/ird/{bin,sbin}. I also had a funtoo system with busybox in
/busybox/{bin,sbin}.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
On Wed, Nov 21, 2018 at 12:17:21PM +, Roger Leigh wrote: > 1) A separate /usr serves no practical purpose on a Debian/Devuan system > >Historically, /usr was separately mountable, shareable over NFS. With a > package manager like dpkg, / and /usr are an integrated, managed whole. > Sharing over NFS is not practical since the managed files span both parts, > and you can't split the package database between separate systems. Modern > disk sizes make partitioning a separate /usr unnecessary and undesirable. > (Both are of course /possible/, but there is precious little to gain by > doing so.) Actually, even on non-modern disk sizes that split isn't good. A decade ago, on N700/N800/N900 Nokia had a tiny boot $DISK and another 64GB in size but noticeably slower. It turned out that / vs /usr is no good for them, and they instead opted for most non-essential binaries on a separate partition on the 64GB eMMC. Both / and /usr were on the small disk with most programs symlinked to the filesystem on /opt . Meow! -- ⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts ⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the ⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism ⠈⠳⣄ (funeral doom metal). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Roger Leigh: ... > 1) A separate /usr serves no practical purpose on a Debian/Devuan system ... Please stop, and please respect the whish of the users who wants a separate /usr, regardless if they are total idiots or seasoned admins. If you want a merged /usr, you can have it, but don't push it on thoose who don't want it. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Mon, Nov 19, 2018 at 06:47:09PM +0100, Didier Kryn wrote: > Le 18/11/2018 à 01:21, Miroslav Skoric a écrit : > > On 11/17/18 3:18 PM, Didier Kryn wrote: > > > > > > > > > > > > > > The advantage of separating /usr is it can be mounted after > > > boot. /bin and /sbin (and /lib) contain the critical applications > > > (and library) necessary to boot the system, and they are, by > > > necessity, part of the root filesystem. Merging /usr means, actually > > > merging /usr/bin with /bin, /usr/sbin with /sbin and /usr/lib with > > > /lib. > > > > > > Merging /usr means all the bloat from /usr/bin and /usr/lib > > > will now be in /bin and /lib (not so much bloat in /usr/sbin). This > > > has very > > > > > > Two more questions: > > > > 1. Installing (too many) software from repositories tends to fill in > > /usr to the point it screams for space (particularly in older machines > > with smaller HDD). However it seems to me that the root filesystem is > > still happy in such cases. But what in case of merger? Can the whole > > system be rendered unusable? (Or screaming?) > > > > 2. What about local compilations of various 3rd party software that > > usually go to /usr/local/bin, sbin, lib, ... in case of merger will they > > all go to the root filesystem? More potential trouble? Yes/No? Tnx. > > > > Misko > > Debian/Devuan's /usr fits easily in say 8GB. Hard to find such small > disks today. So disk space isn't really an issue in my opinion. I'm not > speaking of special embeded or hand-held systems. There is no objection to > making /usr/local a mountpoint. > > Didier Mine is more like 16G, It's still hard to find disks that small. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Wed, Nov 21, 2018 at 01:29:53AM -0500, James Cloos wrote: > > *Everything* currently in /usr should instead be in /. Things that are essential for system startup, and for system diagnosis and recovery (in case it doesnt start properly) should be in the root partition, whatever it is called. Everything else is optional. Wait a moment. Haven't we already done this with /boot? Should we perhaps have /boot/sbin, and so forth? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question
Hi folks, I've been following the discussion with interest. It's certainly not a new discussion, since I remember debating it a good few years back, but there are still the same opinions and thoughts on the topic that I remember from back then. Some general points to consider: 1) A separate /usr serves no practical purpose on a Debian/Devuan system Historically, /usr was separately mountable, shareable over NFS. With a package manager like dpkg, / and /usr are an integrated, managed whole. Sharing over NFS is not practical since the managed files span both parts, and you can't split the package database between separate systems. Modern disk sizes make partitioning a separate /usr unnecessary and undesirable. (Both are of course /possible/, but there is precious little to gain by doing so.) Other systems, like the BSDs, have the effective split between base (/) and ports (/usr/local). / and /usr are still effectively a managed whole containing the "base system". With those points considered, merging / and /usr would make sense. Though equally, keeping the separation doesn't hurt *if they are on the same filesystem*. If they are to be merged, then there are two possibilities: moving /usr to / or the contents of /* to /usr. The point about /usr being a good place for "static" content is a reasonable one. But for better or worse, / is "the system". It's still part of the managed whole, and hiving off a static /usr rather than hiving off the variable changing content isn't really doing more than adding extra unnecessary complexity. 2) Moving the content to /usr doesn't preclude moving it to / later RedHat/systemd have decided to move everything to /usr, and Debian have decided to copy this as they have for most systemd-dictated changes. I'd prefer it to be the other way around; it's cleaner and it's what we would choose given a clean slate. However, when multiple filesystems are in use, /usr is often larger and this is potentially the safer move *for upgrades*. dpkg permits any directory in the filesystem hierarchy to be replaced by a symbolic link. If the contents of /bin, /lib etc. are moved to /usr/bin, /usr/lib etc., they can be replaced by symlinks so that /bin/sh and /lib/ld.so and other fixed paths continue to work correctly. Conversely, /usr can be symlinked to /. This permits /usr/bin/perl to continue to work even if the interpreter is in /bin. However, dpkg must compare canonical paths rather than the package-provided paths, to detect file conflicts between packages using / vs /usr paths. I'm not sure if it does this already or not. There are two parts to the unification: a) Cleaning up all packages such that there are no conflicts between the contents of /bin and /usr/bin b) Moving the files and creating the symlinks The important point to note is that once the cleanup is done, the symlinks can be made to support either scenario. dpkg doesn't care, so long as there are no duplicate files in either location. You could do a migration to /usr on upgrade (for safety) and make /usr a symlink to / on fresh installs. The important part is (a). (b) is policy, which can be changed at will as distribution defaults or local choice. 3) Upgrade incompatibility The point made about the kmod developers switching to /usr/lib makes no sense. If the migration is done correctly, it should be *seamless*. Because /lib should point to /usr/lib, any existing users of /lib should retain using that path for compatibility purposes. Indefinitely, if they cared about doing it properly. No user of /lib should transition to /usr/lib, just like no user of /var/run should have transitioned to /run. The important part of being compatible across filesystem layout changes is not breaking *anything* before or after the unification. 4) None of it actually matters The whole discussion is based on the premise that they are separate. In practice, the vast majority of us have them on the same filesystem, given that there is no practical purpose to the separation as in (1) above. If you are using a container-based system like Docker, or a virtual machine image, or a live image, they will be a single filesystem. If you're doing a standard installation, they will be a single filesystem. Also, if you're using a modern filesystem like ZFS, on Linux: % zfs list -r rpool NAME USED AVAIL REFER MOUNTPOINT rpool 51.0G 56.5G96K none rpool/ROOT 14.6G 56.5G96K none rpool/ROOT/default 14.6G 56.5G 12.0G / rpool/home 3.18M 56.5G96K none rpool/home/root 3.08M 56.5G 3.08M /root rpool/opt 16.3G 56.5G 9.63G /opt rpool/opt/clion 1.19G 56.5G 616M /opt/clion rpool/opt/qt4.34G 56.5G 4.34G /opt/qt rpool/swap 14.3G 62.6G 5.82G - rpool/var
Re: [DNG] /usr to merge or not to merge... that is the question??
Hi Stephan, Stephan Seitz writes: > On Sa, Nov 17, 2018 at 09:14:06 +0900, Olaf Meeuwissen wrote: > >>About that not looking all bad, perhaps the merge should be in the other >>direction, from /usr to / rather than from / to /usr. Or can we expect > > No, if you want to merge something, everything in /usr is the right way. > Then you can really export /usr via NFS to all systems and they have all > programs and libraries available. And you only need to update the /usr > export. Looks like you missed >> # Those are a non-serious suggestion and a rethorical question, in case >> # that didn't come across. ;-) -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Wed, 21 Nov 2018 02:13:24 -0800, Rick wrote in message <20181121101324.gb4...@linuxmafia.com>: > Quoting Arnt Karlsen (a...@iaksess.no): > > > ..yeah, and I really asked about RAID0, the top entry in both: > > https://www.prepressure.com/library/technology/raid#raid-0 or: > > https://www.stellarinfo.co.in/blog/advantages-and-disadvantages-popular-raid-systems/ > > > > ..14 year old performance numbers: > > http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-9.html#ss9.1 > > Apologies: I seem to have misparsed what you asked, twice. Sorry, I > really would have no data on the performance effects of combining > RAID0 and swap, mostly because I've not yet been in a situation where > I've wanted to deploy volume spanning. (Yet, sure, it's great to use > for maximum mass storage performance, so of course there's a > legitimate use-case.) ..aye, 14 years ago I had a 2xPIII box w 5 9GB scsi disks in hotswap drawers to play with, and got drawn into http://groklaw.net/ ... -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Arnt Karlsen (a...@iaksess.no): > ..yeah, and I really asked about RAID0, the top entry in both: > https://www.prepressure.com/library/technology/raid#raid-0 or: > https://www.stellarinfo.co.in/blog/advantages-and-disadvantages-popular-raid-systems/ > > ..14 year old performance numbers: > http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-9.html#ss9.1 Apologies: I seem to have misparsed what you asked, twice. Sorry, I really would have no data on the performance effects of combining RAID0 and swap, mostly because I've not yet been in a situation where I've wanted to deploy volume spanning. (Yet, sure, it's great to use for maximum mass storage performance, so of course there's a legitimate use-case.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Wed, 21 Nov 2018 01:12:22 -0800, Rick wrote in message <20181121091222.ga4...@linuxmafia.com>: > Quoting Arnt Karlsen (a...@iaksess.no): > > > > In any event, I gather that there are tradeoffs. > > > https://unix.stackexchange.com/questions/15052/what-are-the-advantages-of-swap-on-a-raid-1-mirror-device > > > https://www.linuxjournal.com/article/5898 > > > > ..hum, looks like you read my question on "swap on RAID0 or not", > > as "swap on RAID1 or not", where tradeoffs will be different. > > Um, did you really check those links, though? I've just done a quick > recheck. Looks to me like both pages are (primarily) about swap > across RAID1 md5 mirrored devices. ..yeah, and I really asked about RAID0, the top entry in both: https://www.prepressure.com/library/technology/raid#raid-0 or: https://www.stellarinfo.co.in/blog/advantages-and-disadvantages-popular-raid-systems/ ..14 year old performance numbers: http://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-9.html#ss9.1 -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Who left the barn door open? -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
Quoting Arnt Karlsen (a...@iaksess.no): > > In any event, I gather that there are tradeoffs. > > https://unix.stackexchange.com/questions/15052/what-are-the-advantages-of-swap-on-a-raid-1-mirror-device > > https://www.linuxjournal.com/article/5898 > > ..hum, looks like you read my question on "swap on RAID0 or not", > as "swap on RAID1 or not", where tradeoffs will be different. Um, did you really check those links, though? I've just done a quick recheck. Looks to me like both pages are (primarily) about swap across RAID1 md5 mirrored devices. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] /usr to merge or not to merge... that is the question??
On Tue, 20 Nov 2018 23:52:19 -0800, Rick wrote in message <20181121075219.gz4...@linuxmafia.com>: > Quoting Arnt Karlsen (a...@iaksess.no): > > > ..is/was these 2 separate swap spaces faster stand-alone than put > > together in a RAID0? > > I'm not sure. Adding the additional complication of the md layer to > the Linux swapper thread's management of alternate access between two > swap partitions with equal priority seemed really unwise and _likely_ > to (at least) complicate operation, so I avoided doing so on the > general sentiment of simplicity. > > In any event, I gather that there are tradeoffs. > https://unix.stackexchange.com/questions/15052/what-are-the-advantages-of-swap-on-a-raid-1-mirror-device > https://www.linuxjournal.com/article/5898 ..hum, looks like you read my question on "swap on RAID0 or not", as "swap on RAID1 or not", where tradeoffs will be different. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
