[PATCH setup 00/10] Various setup patches

[Corinna Vinschen]

On Aug  3 11:51, Achim Gratz wrote:
> Corinna Vinschen writes:
> > *If* we do that, the setup files should go under /var/lib/setup.
> 
> Yes.
> 
> > However, why would this make sense exactly?  Yes, I know LSB and yada
> > yada, but why *exactly* would that make sense in *our* situation?
> 
> In this case it's just a clean way to separate the old and new databases.
> 
> >> 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.
> 
> The way we're installing at the moment we could just hardlink.

If the filesystem supports it.  We *might* get away with the assumption
the underlying filesystem is NTFS or similar, but even a newer FS like
ReFS has no hardlinks :(

> > 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?
> 
> Maybe we could just rename installed.db to installed.db3 or seomthing
> similar.

In the current state of Jon's patch that shouldn't be necessary, but
whatever you do, you don't drop the requirement that tools like
cygcheck, cygcheck-dep or _autorebase have to adapt.

> >> 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.
> 
> Yes, but you'll still have to come up with some encoding and it would be
> awfully nice if the new file format was a bit more forward-thinking when
> it comes to extensibility.

I don't think that's really necessary as long as you *add* information.
What's really important is to check and, if required, change cygcheck
and friends to be able to skip information they don't evaluate, rather
than choking on it.

> > 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.
> 
> That would be either supplemental files with the hashes or some new .lst
> format which could/should use a different extension anyway since the
> transition period will be long.

Why?  The transition period can be very much shortened if we do what
I wrote above.

> >> >   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.

In terms of all of the above, I'd like to see some input from Jon, Yaakov
et al.

> > .cpm sounds a bit... old-fashioned ;)
> 
> I still have one of these, not that I've run it in the last few years:
> http://www.robotron-net.de/pc_s.html#BIC

Wow!


Thanks,
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/453233fa/attachment.sig>