Re: support for merged /usr in Debian
On Dec 31, Bastien ROUCARIES wrote: > It is not only about lintian it is about the quality of your maintscript. My maintscripts are a total of four commands and they have used for at least 9 months in packages with priority important (nano) and required (debianutils), with no problems reported. If you believe that they are unsuitable then I think that at this point it is on you to explain more clearly why. > Moreover you do not > check the existance of dpkg-divert in > https://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/convert-usrmerge > This is a RC bug to continue if they are dpkg-divert in place. Any bugs that may be in the usrmerge package are not related to merging the new lintian checks, but if you could explain in more detail which divert-related issues you are thinking are affecting convert-usrmerge then I will be happy to address them. > Moreover quoting guillem and me about creating symlink for library > under /lib if a pakage install both file in /lib /usr/lib Now I get this part: I will split the lintian check in two. > >In addition, from what I've seen from the submitted patches, I'd > >probably check for the ownership of the pathname being symlinked to > >or removed, and if it is owned by another package bail out. Because > >dpkg will not be performing such checks at unpack time. > Thus we want to check if the dpkg maint script applied in case of > conflicts are good. And it is not a lintian problem. This would add a lot of complexity for no obvious benefit: please explain more clearly what this would solve. -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote: > https://wiki.debian.org/UsrMerge Now that we have union mounts in Linux, should we instead do what Ken Thompson and Dennis Ritchie should have done; install things in / instead of /usr and use union mounts when there is one small disk containing some files and a larger disk containing other files? http://lists.busybox.net/pipermail/busybox/2010-December/074114.html I presume Hurd can do union mounts, not sure about kFreeBSD though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: support for merged /usr in Debian
On Fri, Jan 01, 2016 at 06:20:42PM +0800, Paul Wise wrote: > On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote: > > > https://wiki.debian.org/UsrMerge > > Now that we have union mounts in Linux, should we instead do what Ken > Thompson and Dennis Ritchie should have done; install things in / > instead of /usr and use union mounts when there is one small disk > containing some files and a larger disk containing other files? +1. /usr is a historical artefact, why would we mandate it forever? Let's follow the Hurd way of /bin /sbin rather than /usr/bin /usr/sbin. A symlink /usr -> / is easier to implement (and benefits from most of the work already done for UsrMerge). -- A tit a day keeps the vet away.
Re: support for merged /usr in Debian
Paul Wise writes: > On Thu, Dec 31, 2015 at 8:51 AM, Marco d'Itri wrote: >> https://wiki.debian.org/UsrMerge > > Now that we have union mounts in Linux, should we instead do what Ken > Thompson and Dennis Ritchie should have done; install things in / > instead of /usr and use union mounts when there is one small disk > containing some files and a larger disk containing other files? Moving /bin, /sbin, /lib to /usr has some advantages like being able to mount /usr read-only while keeping /etc read-write. Or sharing /usr between multiple containers and having them only use a different / with different /etc and /var. Moving everything from /usr to / doesn't seem to bring any such advantages? So I don't see why we would want to do so. Ansgar
Re: support for merged /usr in Debian
m...@linux.it (Marco d'Itri) writes: > Thanks to my conversion program in usrmerge there is no need for a flag > day, archive rebuilds or similar complexity and we can even continue to > support unmerged systems. Is there any use case that requires supporting unmerged systems? It's simpler to support just merged-/usr and avoids the problem that sometimes a binary will be in both /bin and /usr/bin (with merged-/usr) and sometimes only in one location. That sounds like a source of bugs that have a good potential to be found only too late... Ansgar
Re: support for merged /usr in Debian
Hi, On 01.01.2016 12:23, Ansgar Burchardt wrote: > Is there any use case that requires supporting unmerged systems? Booting without an initrd, which is important for resource-constrained embedded systems. I have a system that boots in three seconds, which is fairly long already. Adding an initrd would extend that to five seconds and require a twenty minute rebuild of the initrd on upgrade. Using an initrd would also add new failure modes where the initrd build fails because of memory constraints (e.g. because an application process is stuck in D state and did not terminate when we entered the "system update" runlevel). > It's simpler to support just merged-/usr and avoids the problem that > sometimes a binary will be in both /bin and /usr/bin (with merged-/usr) > and sometimes only in one location. That sounds like a source of bugs > that have a good potential to be found only too late... I agree that it should be a bug to have binaries with the same name in both locations. Simon signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On Fri, Jan 01, 2016 at 12:23:20PM +0100, Ansgar Burchardt wrote: > m...@linux.it (Marco d'Itri) writes: > > Thanks to my conversion program in usrmerge there is no need for a flag > > day, archive rebuilds or similar complexity and we can even continue to > > support unmerged systems. > > Is there any use case that requires supporting unmerged systems? I don't think so. You already need the / filesystem, and with today storage sizes, if you can hold that, you can hold the whole system, period. Even on any embedded that can run Debian. The last time I've seen a split done due to small / was Maemo ten years ago. And guess what? They didn't use / vs /usr but hacked something where both / and /usr were on the small mmc while big /opt hold most of the files, with symlinks from /usr. That's because their needs were different from those of Ken Thompson in 1971. A reasonable and often important split is keeping /+/usr apart from a box's main purpose, be it /home, /srv or /var/lib/postgresql -- but in any case both / and /usr will be on the same filesystem. Thus, I'd say /usr is pointless on any machine we can reasonably support. -- A tit a day keeps the vet away.
Re: support for merged /usr in Debian
On Fri, Jan 1, 2016 at 7:17 PM, Ansgar Burchardt wrote: > Moving /bin, /sbin, /lib to /usr has some advantages like being able to > mount /usr read-only while keeping /etc read-write. Or sharing /usr > between multiple containers and having them only use a different / with > different /etc and /var. One can mount / read-only while keeping /etc read-write. I would guess one can have / shared by containers but /etc and /var different. -- bye, pabs https://wiki.debian.org/PaulWise
Re: support for merged /usr in Debian
On 2016-01-01 13:39:35, Adam Borowski wrote: > On Fri, Jan 01, 2016 at 12:23:20PM +0100, Ansgar Burchardt wrote: > > m...@linux.it (Marco d'Itri) writes: > > > Thanks to my conversion program in usrmerge there is no need for a flag > > > day, archive rebuilds or similar complexity and we can even continue to > > > support unmerged systems. > > > > Is there any use case that requires supporting unmerged systems? > > I don't think so. You already need the / filesystem, and with today storage > sizes, if you can hold that, you can hold the whole system, period. Even on > any embedded that can run Debian. > > The last time I've seen a split done due to small / was Maemo ten years ago. > And guess what? They didn't use / vs /usr but hacked something where both / > and /usr were on the small mmc while big /opt hold most of the files, with > symlinks from /usr. That's because their needs were different from those of > Ken Thompson in 1971. > > A reasonable and often important split is keeping /+/usr apart from a box's > main purpose, be it /home, /srv or /var/lib/postgresql -- but in any case > both / and /usr will be on the same filesystem. > > Thus, I'd say /usr is pointless on any machine we can reasonably support. I respectfully disagree. Having / contain basically only /etc means we finally have a full separation between configuration (/), binaries (/usr) and state (/var), which opens up some interesting options in the field of large-scale virtualisation. regards, iustin signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Fri, Jan 1, 2016 at 8:39 PM, Adam Borowski wrote: > I don't think so. You already need the / filesystem, and with today storage > sizes, if you can hold that, you can hold the whole system, period. Even on > any embedded that can run Debian. I'm reminded of the posts by Joey Hess in 2007: https://wiki.debian.org/RootSync https://joeyh.name/blog/entry/embedding_debian/ -- bye, pabs https://wiki.debian.org/PaulWise
Bug#694308: non-DFSG postscript embedded in fontforge
On Fri, Jan 1, 2016 at 4:54 AM, Hideki Yamane wrote: > On Mon, 28 Dec 2015 13:55:48 +0100 > Bastien ROUCARIES wrote: >>If it is GPL-2+ it is not a problem but a few fonts file are released >>under GPL-2 only... It is quite a mess. > > Yes... The best way to solve it is re-license those snippets to more > permissive license like BSD-3-clause or MIT by Adobe, but it costs for > them. Yes MIT will be best > >>> And, how can I think about fontforge copies snippet to generate those >>> *.pfb files? >> >>Could you modify comment on this code to add some fontforge comment ? >>Like for instance "inserted by fontforge (debian someversion)". I >>could teach lintian to check if font are regenerated. >>What do you think? > > Probably I can, but is it necessary? Re-licensed to Apache-2.0 code is > exactly same as previous proprietary one, no changes. Just treat it as > DFSG-free code is enough, isn't it? No, it will help me on the lintian to get not rebuilt at build time fonts... Best will be to add a timestamp but i think it destroy reproductible build step, so if timestamp could be overriden by an env variable (so it could be set to last changelog entry timestamp) and disable by a command line flags it will be good. Bastien > > -- > Regards, > > Hideki Yamane henrich @ debian.or.jp/org > http://wiki.debian.org/HidekiYamane
Re: support for merged /usr in Debian
❦ 1 janvier 2016 13:29 +0100, Simon Richter : >> Is there any use case that requires supporting unmerged systems? > > Booting without an initrd, which is important for resource-constrained > embedded systems. Do you also require a separate /usr for those systems? -- The human race has one really effective weapon, and that is laughter. -- Mark Twain signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Fri, Jan 01, 2016 at 01:29:09PM +0100, Simon Richter wrote: > On 01.01.2016 12:23, Ansgar Burchardt wrote: > > > Is there any use case that requires supporting unmerged systems? > > Booting without an initrd, which is important for resource-constrained > embedded systems. > > [reasons for !initrd] No one is proposing dropping support for no-initrd in the general case, just for separate /usr. Legacy systems with such a split would indeed require an initrd, but those are unlikely to be embedded (cf Maemo where /usr was inadequate). -- A tit a day keeps the vet away.
Re: support for merged /usr in Debian
On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri wrote: > On Dec 31, Bastien ROUCARIES wrote: > >> It is not only about lintian it is about the quality of your maintscript. > My maintscripts are a total of four commands and they have used for at > least 9 months in packages with priority important (nano) and required > (debianutils), with no problems reported. > If you believe that they are unsuitable then I think that at this point > it is on you to explain more clearly why. It is not a proof of non existance of black swan. And nine month is insuffisant for eprouved by time and you have only a popcon of 3... > >> Moreover you do not >> check the existance of dpkg-divert in >> https://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/convert-usrmerge >> This is a RC bug to continue if they are dpkg-divert in place. > Any bugs that may be in the usrmerge package are not related to merging > the new lintian checks, but if you could explain in more detail which > divert-related issues you are thinking are affecting convert-usrmerge > then I will be happy to address them. Ok if a target or src file is a dpkg-divert it means admin has done some override. You do not know admin whishes so best is to stop in preinst step. > >> Moreover quoting guillem and me about creating symlink for library >> under /lib if a pakage install both file in /lib /usr/lib > Now I get this part: I will split the lintian check in two. > >> >In addition, from what I've seen from the submitted patches, I'd >> >probably check for the ownership of the pathname being symlinked to >> >or removed, and if it is owned by another package bail out. Because >> >dpkg will not be performing such checks at unpack time. >> Thus we want to check if the dpkg maint script applied in case of >> conflicts are good. And it is not a lintian problem. > This would add a lot of complexity for no obvious benefit: please > explain more clearly what this would solve. See with guillem. And could be possible to get on the wiki page the maintscript snippet used by maintscript of package with conflict file. Guillem and me will like to review your work. Bastien > -- > ciao, > Marco
Re: support for merged /usr in Debian
On Fri, Jan 1, 2016 at 2:22 PM, Bastien ROUCARIES wrote: > On Fri, Jan 1, 2016 at 10:46 AM, Marco d'Itri wrote: >> On Dec 31, Bastien ROUCARIES wrote: >> >>> It is not only about lintian it is about the quality of your maintscript. >> My maintscripts are a total of four commands and they have used for at >> least 9 months in packages with priority important (nano) and required >> (debianutils), with no problems reported. >> If you believe that they are unsuitable then I think that at this point >> it is on you to explain more clearly why. > > It is not a proof of non existance of black swan. And nine month is > insuffisant for eprouved by time and you have only a popcon of 3... >> >>> Moreover you do not >>> check the existance of dpkg-divert in >>> https://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/convert-usrmerge >>> This is a RC bug to continue if they are dpkg-divert in place. >> Any bugs that may be in the usrmerge package are not related to merging >> the new lintian checks, but if you could explain in more detail which >> divert-related issues you are thinking are affecting convert-usrmerge >> then I will be happy to address them. > > Ok if a target or src file is a dpkg-divert it means admin has done > some override. > > You do not know admin whishes so best is to stop in preinst step. > > >> >>> Moreover quoting guillem and me about creating symlink for library >>> under /lib if a pakage install both file in /lib /usr/lib >> Now I get this part: I will split the lintian check in two. >> >>> >In addition, from what I've seen from the submitted patches, I'd >>> >probably check for the ownership of the pathname being symlinked to >>> >or removed, and if it is owned by another package bail out. Because >>> >dpkg will not be performing such checks at unpack time. >>> Thus we want to check if the dpkg maint script applied in case of >>> conflicts are good. And it is not a lintian problem. >> This would add a lot of complexity for no obvious benefit: please >> explain more clearly what this would solve. > > See with guillem. > > And could be possible to get on the wiki page the maintscript snippet > used by maintscript of package with conflict file. Guillem and me will > like to review your work. For instance maintscript suggested here [1] is totally buggy: * postrm is buggy because you do not check if link target is consistant with postinst * postrm is buggy because you do not check for existance of dpkg-divert of /usr/sbin/load_policy * postrm is buggy because you do not check if /sbin/load_policy is owned by policycoreutils * postinst is buggy because you do not check if /sbin/load_policy is owned by policycoreutils So please get some review [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767930 > Bastien > >> -- >> ciao, >> Marco
Re: support for merged /usr in Debian
Ansgar Burchardt writes ("Re: support for merged /usr in Debian"):
> m...@linux.it (Marco d'Itri) writes:
> > Thanks to my conversion program in usrmerge there is no need for a flag
> > day, archive rebuilds or similar complexity and we can even continue to
> > support unmerged systems.
>
> Is there any use case that requires supporting unmerged systems?
Someone has already mentioned mounting /usr ro. But one generally has
to keep /etc rw. I don't think that the right way to address this is
to make /etc a mount point.
Anotheer example: I have a system which does a rather hackish NFS root
boot. It has its own / but uses /usr from the fileserver. This has
worked surprisingly well for a long time.
Ian.
Re: support for merged /usr in Debian
Hi, On 01.01.2016 14:28, Vincent Bernat wrote: >> Booting without an initrd, which is important for resource-constrained >> embedded systems. > Do you also require a separate /usr for those systems? My current system doesn't, but I might need it in the future because mounting /usr takes an awfully long time, because it is a jffs2. Simon signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
Ian Jackson writes:
> Ansgar Burchardt writes ("Re: support for merged /usr in Debian"):
>> m...@linux.it (Marco d'Itri) writes:
>> > Thanks to my conversion program in usrmerge there is no need for a flag
>> > day, archive rebuilds or similar complexity and we can even continue to
>> > support unmerged systems.
>>
>> Is there any use case that requires supporting unmerged systems?
>
> Someone has already mentioned mounting /usr ro. But one generally has
> to keep /etc rw. I don't think that the right way to address this is
> to make /etc a mount point.
Well, that is one of the reasons to move /{s,}bin and /lib to /usr: by
doing so mounting /usr read-only covers more static files.
/etc can live either on a rw root or on an extra partition (provided the
initramfs does the right thing). Note that /etc will *not* move to
/usr/etc.
> Anotheer example: I have a system which does a rather hackish NFS root
> boot. It has its own / but uses /usr from the fileserver. This has
> worked surprisingly well for a long time.
Hmm, such systems would probably need reworking with a merged-/usr. I
think if one does something like this, the system should treat its local
/ like a initramfs and just chroot into the nfs-provided filesystem.
One can mount /etc or other filesystems from the local system too if
needed.
Also for the general /usr-on-network and /-local case, it is unclear
what would need to be provided in /. As far as I understand with more
interesting setups, one needs to move more and more of /usr to / to
support that... Say for /usr-over-some-encrypted-network or
/usr-over-interesting-network-protocol or even /usr-over-wlan.
Ansgar
Re: support for merged /usr in Debian
On Jan 01, Ian Jackson wrote: > Someone has already mentioned mounting /usr ro. But one generally has > to keep /etc rw. I don't think that the right way to address this is > to make /etc a mount point. I am not aware of any plan to make /etc a mount point, which indeed would pointless. On a merged /usr system the root file system only contains /boot, /etc, /var and /home while the OS proper is all in /usr. > Anotheer example: I have a system which does a rather hackish NFS root > boot. It has its own / but uses /usr from the fileserver. This has > worked surprisingly well for a long time. With a merged /usr you would be able to serve the whole OS over NFS (and even share it among multiple systems without the constant threat of having / and /usr diverge) and only configuration + data from the local disk, which makes this kind of setup much more useful. -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Jan 01, Bastien ROUCARIES wrote: > > My maintscripts are a total of four commands and they have used for at > > least 9 months in packages with priority important (nano) and required > > (debianutils), with no problems reported. > > If you believe that they are unsuitable then I think that at this point > > it is on you to explain more clearly why. > It is not a proof of non existance of black swan. And nine month is > insuffisant for eprouved by time and you have only a popcon of 3... These maintscripts are installed on every Debian system, so the popcon count of usrmerge is not relevant. It is doubly not relevant because their code is never triggered on merged /usr systems, since the target files on them would not be symlinks. > Ok if a target or src file is a dpkg-divert it means admin has done > some override. > You do not know admin whishes so best is to stop in preinst step. The *bin directories contain files diverted by packages on every system and this does break the conversion script. Please show a configuration and explain how it would break the conversion. > For instance maintscript suggested here [1] is totally buggy: > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767930 I do not believe that adding this complexity to the maintainer scripts is justified, i.e. I do not believe that it would solve more problems than the ones it may create. The maintainers of these packages are free to implement the creation of the symlink on unmerged systems however they think is appropriate, but I am not comfortable in suggesting to use more complex code and it is not up to you either as a lintian maintainer to impose it. So, unless there is a consensus on debian-devel@ that there are real world cases where the simple maintscripts proposed are not appropriate I have no plans to change them. -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Fri, 2016-01-01 at 20:55 +0800, Paul Wise wrote: > On Fri, Jan 1, 2016 at 7:17 PM, Ansgar Burchardt wrote: > > > Moving /bin, /sbin, /lib to /usr has some advantages like being able to > > mount /usr read-only while keeping /etc read-write. Or sharing /usr > > between multiple containers and having them only use a different / with > > different /etc and /var. > > One can mount / read-only while keeping /etc read-write. > > I would guess one can have / shared by containers but /etc and /var different. So far as I know, /etc as a separate filesystem isn't supported by any init system or by initramfs-tools. (Roger Leigh did some work on it but it was not completed and it needed extra kernel parameters.) Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken. signature.asc Description: This is a digitally signed message part
Bug#809612: ITP: ruby-rubinius-debugger -- Rubinius debugger.
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: ruby-rubinius-debugger Version : 2.2.1-1 Upstream Author : Brian Shirai * URL : https://github.com/rubinius/rubinius-debugger * License : BSD Programming Lang: Ruby Description : Rubinius debugger.
Bug#809613: ITP: ruby-rubinius-coverage -- Rubinius coverage tool
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: ruby-rubinius-coverage Version : 2.0.3-1 Upstream Author : Brian Shirai * URL : https://github.com/rubinius/rubinius-coverage * License : BSD Programming Lang: Ruby Description : Rubinius coverage tool
Bug#809615: ITP: ruby-rubinius-profiler -- Rubinius profiler.
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: ruby-rubinius-profiler Version : 2.0.2-1 Upstream Author : Brian Shirai * URL : https://github.com/rubinius/rubinius-profiler * License : BSD Programming Lang: Ruby Description : Rubinius profiler.
Bug#809616: ITP: ruby-rubinius -- A meta-gem for all the Rubinius components that are provided as gems
Package: wnpp Severity: wishlist Owner: "Andrew Lee (李健秋)" * Package name: ruby-rubinius Version : 2.0.1-1 Upstream Author : Brian Shirai * URL : http://rubini.us * License : BSD Programming Lang: Ruby Description : A meta-gem for all the Rubinius components that are provided as gems
