[PATCH setup 00/10] Various setup patches

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Aug 3 08:35:00 GMT 2016


On Aug  3 09:10, Achim Gratz wrote:
> Jon Turney writes:
> >   Track if a package was installed by user, or as a dependency
> >   Add an additional filter view, showing packages which were user picked
> 
> As a suggestion (and I won't have time for implementation help at the
> moment): Please consider keeping /etc/setup/installed.db at version 2
> and instead move the new-style database(s) to somewhere under
> /var/setup.

*If* we do that, the setup files should go under /var/lib/setup.

However, why would this make sense exactly?  Yes, I know LSB and yada
yada, but why *exactly* would that make sense in *our* situation?

> For some time we would have to generate both the old and
> new databases from setup of course until everything has switched over to
> the new locations. 

Moving from /etc/ to /var requires to move all files.  It's useless
if the lst files stay in /etc while the db and rc files go to /var.

That means, a move to /var requires to copy/move the lst files over in a
single step, even (especially) the old ones, otherwise you'd have a
broken database, with files in /etc and /var.

Who's going to do this?  Setup itself would have to do it since a
post-install script would be too late.  So you'd have to write code
into setup for just this move to /var.  Code which runs exactly once.

And then writing *both* at the same time?  What packages are the
consumers of the data in /etc/setup?  AFAICS, cygwin itself (cygcheck),
cygcheck-dep, and _autorebase only.

Wouldn't it make more sense either to stick to /etc/setup, or to
change all three packages to check for /var/lib/setup and use that
if it exists, /etc/setup otherwise?

> The format of the new database is up for discussion
> I think, but besides the distinction between picked and non-picked I
> think there should be a way to record version locks or preferences for
> prev/curr/test.

I think the old "size" field should become a flag field instead, with
picked/non-picked having the bit value 1.  That covers a lot of info
already.

> I would also like to add checksums to the package lists, provided we can
> find a way to ignore the changes due to rebasing, so it becomes easier to
> audit an installation for changes.

Feel free to add stuff.  Just make sure the (hopefully only) three
dependent packages can work with the new format before we introduce the
new format.

> >   Reserve paths starting "." for package metadata
> 
> What did you envision here?  In general I like the idea, but when we
> start to have a structured package format I think we should move to some
> other naming convention than .tar.xz, like .cyg or .cpm perhaps.

.cpm sounds a bit... old-fashioned ;)


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20160803/4602416a/attachment.sig>


More information about the Cygwin-apps mailing list