From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-apps@cygwin.com
Subject: Re: [PATCH setup 00/10] Various setup patches
Date: Wed, 03 Aug 2016 17:40:00 -0000 [thread overview]
Message-ID: <20160803173949.GB25811@calimero.vinschen.de> (raw)
In-Reply-To: <87k2fyyyby.fsf@Rainer.invalid>
[-- Attachment #1: Type: text/plain, Size: 3596 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-08-03 17:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 15:31 Jon Turney
2016-08-02 15:31 ` [PATCH setup 10/10] Reserve paths starting "." for package metadata Jon Turney
2016-08-02 15:31 ` [PATCH setup 05/10] Properly report progress in PrereqChecker::isMet Jon Turney
2016-08-02 15:31 ` [PATCH setup 02/10] Prevent libtool warning that a getopt++ shared library cannot be built Jon Turney
2016-08-02 15:31 ` [PATCH setup 03/10] Add lex and yacc generated files to .gitignore Jon Turney
2016-08-02 15:31 ` [PATCH setup 07/10] Remove unused fn member from cygpackage Jon Turney
2016-08-02 15:31 ` [PATCH setup 09/10] Add an additional filter view, showing packages which were user picked Jon Turney
2016-08-02 15:31 ` [PATCH setup 01/10] Remove stray execute permissions Jon Turney
2016-08-02 15:31 ` [PATCH setup 08/10] Track if a package was installed by user, or as a dependency Jon Turney
2016-08-03 10:49 ` Jon Turney
2016-08-02 15:31 ` [PATCH setup 04/10] Downgrade "Running preremove script" logging to debug Jon Turney
2016-08-02 15:31 ` [PATCH setup 06/10] Remove obsolete installed_from member from packagemeta Jon Turney
2016-08-03 7:10 ` [PATCH setup 00/10] Various setup patches Achim Gratz
2016-08-03 8:35 ` Corinna Vinschen
2016-08-03 9:52 ` Achim Gratz
2016-08-03 17:40 ` Corinna Vinschen [this message]
2016-08-03 18:28 ` Achim Gratz
2016-08-03 18:43 ` Corinna Vinschen
2016-08-03 19:52 ` Achim Gratz
2016-08-04 11:40 ` Corinna Vinschen
2016-08-04 17:57 ` Achim Gratz
2016-08-04 18:00 ` Corinna Vinschen
2016-08-04 19:26 ` Achim Gratz
2016-08-03 17:30 ` Corinna Vinschen
2017-05-23 16:46 Jon Turney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160803173949.GB25811@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).