Simon McVittie <smcv@debian.org> writes: > Should we be more specific than this in what we vote on, to avoid > later having to adjudicate between developers who say that a particular > implementation is or isn't merged-usr? I think that and a transition plan are both key to this project. I recently installed Debian from scratch on my HiFive unmatched board and it got merged / and /usr. When I built packages on this device, they created invalid packages as the shared library dependencies all listed /lib instead of /usr/lib. That seems like a non-starter to me. Any plan where a transitioning system cannot be used for ongoing Debian development seems unworkable to me -- it leaves all active Debian developers working on un-transitioned systems, which greatly reduces test coverage from people in the best position to help fix things. I do use a separate cowbuilder when creating packages to upload, and that could be configured in un-transitioned mode, but I also regularly debug packages on my native system as that offers much faster development times. > Guillem considers layout 1 to be broken and a mess. I don't agree, > but I'm not a dpkg maintainer. We should be aware that mandating this > implementation is likely to require some overruling. From an architectural purity perspective, layout 1 'looks nicer'. As that also matches what other distros are doing, it would make us more consistent across the Linux ecosystem (I believe that's a good thing). However, I believe only layout 2a would make it possible to build Debian packages on transitioned systems. That seems necessary to me. We could, in future, then transition from layout 2a to layout 1 once /lib (and /bin?) were no longer in the default search paths to cause invalid packages to be created. I don't understand the value of 2b; it's functionally similar to layout 1, but makes for additional work to create the shadow links, along with consuming space for them. It also doesn't resolve the problem of building packages. > Sorry to derail this but I think we should be clear about what we're > resolving. I think you've added helpful clarification to the conversation, thanks! -- -keith
Attachment:
signature.asc
Description: PGP signature