Autor: Boruch Baum Data: A: dng Assumpte: Re: [DNG] On the wisdom on netboot installer images
On 03/21/2016 09:02 PM, Hendrik Boom wrote: > On Mon, Mar 21, 2016 at 05:19:33PM -0400, Boruch Baum wrote:
>>
>> 3] One complicated solution would be to not destroy
>> /var/cache/apt/archive on the target when re-installing. It could be
>> done by having the installer suggest to mount that folder on its own
>> partition, and then have the installer refer to it at the download stage.
>
> You'd have to be able to check that the /var/cache was for the same
> distro as the one you were testing. Technically, that's right. In practice, I would suggest that it's
reasonable to put some responsibility on the shoulders of the user who
elects this option. At first, devuan would be the innovator, so there
would be no other distro with a reality of a /var/cache/apt/archive
mount point partition. If the idea makes sense and would get adopted by
other distros, it would only become an issue among families of linuxes
that use the same package extensions (eg deb, rpm). For a user who would
opt for a common partition for archiving packages from installs of
multiple distributions of the same extension, if the filenames were
identical, their key-signing would also need to match. Were the
keysigning to fail on an archived version of a package, ? (I don't know
how apt-get responds - does it recover by downloading a new copy? does
it force a sysadmin to manually rm the offender?)
So my guess is that the trouble would only arise when:
1] multiple distros use the technique
2] user is testing those multiple distros simultaneously
3] user uses the same partition for the mount points
4] they are the same package management familly (deb/rpm/etc)
5] the distros don't check the package keysig, or something 'bad' and
unrecoverable happens when they fail to match
Your point is prudent and in-place, that if devuan wanted to adopt the
technique, it should pro-actively have some fail-safe measure. What
comes to mind initially would be a label file, identifying to future
installs the identity of the previous one. Any distro adopting the
technique would be expected to check for the identity file, and reject
the mount point if it wasn't its own. The identiy file could be a simple
agreed-upon file name with a short text desciption of the distro that
put it there. Maybe allow it in the form foo.bar where foo is the
extension used by the package manager for the distro and bar is the
agreed upon name, so that distros of different package families could
co-exist in the same folder. Thus there could be files
rpm.identity_filename_standard and deb.rpm.identity_filename_standard in
the same folder, along with however many debs and rpms. That's a bit
blue-sky and edge-case, but worth spec-ing out as an option.