[PATCH setup 00/10] Various setup patches
Oh, I think I can see a bit of floor over there! Jon Turney (10): isBinary() should return true for orphaned packages Correctly calculate total data to checksum when using IncludeSource Rename category "Misc" to "Orphaned" Make PrereqChecker::setTrust() a static method Move and rename dumpAndList() Fold IniDBBuilderPackage::buildInstallSize() into buildPackageInstall() Fold build(Install|Source)(MD5|SHA512) into buildPackage(Install|Source) Fix infinite recursion in grammar for depends Improve error recovery in setup.ini parsing Remove OR from grammar IniDBBuilderPackage.cc | 88 ++ IniDBBuilderPackage.h | 21 Makefile.am| 1 + ScanFindVisitor.cc | 4 +-- choose.cc | 5 ++- inilex.ll | 3 +- iniparse.yy| 26 ++- install.cc | 2 +- package_db.cc | 2 +- package_depends.cc | 33 +++ package_depends.h | 3 ++ package_meta.cc| 8 ++--- package_version.cc | 18 --- package_version.h | 3 -- prereq.h | 2 +- 15 files changed, 118 insertions(+), 101 deletions(-) create mode 100644 package_depends.cc -- 2.12.3
Re: [PATCH setup 00/10] Various setup patches
On Aug 4 19:56, Achim Gratz wrote: > Corinna Vinschen writes: > >> The checksum information has to come from somewhere and that somewhere > >> requires a package install or update. Together with that new setup we > >> might > >> have an update of cygccheck and some unrelated packages that happen to > >> have been rebuilt recently, but certainly not the whole distribution. > > > > Why is that important? The checksums will collect over time. > > That's the plan, but then you'll have to deal with missing checksums > while that particular strand of hair grows out. > > > I don't think I understand what you're up to. Why is it important > > to add the extra information all at once? And if that's the case, > > couldn't we use a runonce postinstall script for that? > > I was interpreting your reply that you wanted the tools to only support > the new list formats. Oh, no, sorry if I was unclear but I would like the tools just to adapt so that they don't choke on new formats while still working happily on the old formats. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [PATCH setup 00/10] Various setup patches
Corinna Vinschen writes: >> People tend to not re-install their whole set of packages just because >> some new version of setup is announced, > > Uhm? If you download a new setup, but then don't update your packages, > why did you download the latest setup at all? If you don't run this > new setup, you won't get new-style files. The checksum information has to come from somewhere and that somewhere requires a package install or update. Together with that new setup we might have an update of cygccheck and some unrelated packages that happen to have been rebuilt recently, but certainly not the whole distribution. >> so I'm going to assume that for >> quite some time a mix of old and new .lst files (for instance) exists on >> the majority of installations and whatever we do (in cygcheck, say) >> needs to work with that. > > 1. Provide new versions of cygwin, cygcheck-dep and _autorebase > 2. time passes (2 weeks or so) > 3. Provide a new version of setup That doesn't cut it, unless you want to require the whole distribution to be rebuilt and everything re-installed with that change. Cygwin10 1609 or something like that? :-) Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [PATCH setup 00/10] Various setup patches
On Aug 3 20:27, Achim Gratz wrote: > Corinna Vinschen writes: > >> 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. > > People tend to not re-install their whole set of packages just because > some new version of setup is announced, Uhm? If you download a new setup, but then don't update your packages, why did you download the latest setup at all? If you don't run this new setup, you won't get new-style files. > so I'm going to assume that for > quite some time a mix of old and new .lst files (for instance) exists on > the majority of installations and whatever we do (in cygcheck, say) > needs to work with that. 1. Provide new versions of cygwin, cygcheck-dep and _autorebase 2. time passes (2 weeks or so) 3. Provide a new version of setup Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [PATCH setup 00/10] Various setup patches
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 signature.asc Description: PGP signature
Re: [PATCH setup 00/10] Various setup patches
On Aug 2 16:30, Jon Turney wrote: > Jon Turney (10): > Remove stray execute permissions > Prevent libtool warning that a getopt++ shared library cannot be built > Add lex and yacc generated files to .gitignore > Downgrade "Running preremove script" logging to debug > Properly report progress in PrereqChecker::isMet > Remove obsolete installed_from member from packagemeta > Remove unused fn member from cygpackage > Track if a package was installed by user, or as a dependency > Add an additional filter view, showing packages which were user picked > Reserve paths starting "." for package metadata > > .gitignore | 3 + > KeysSetting.cc | 0 > KeysSetting.h | 0 > PickView.cc | 16 +++-- > PickView.h | 4 +- > crypto.cc | 0 > crypto.h| 0 > cyg-pubkey.h| 0 > cygpackage.cc | 3 - > cygpackage.h| 8 +-- > cygwin.pub | Bin > gpg-packet.cc | 0 > gpg-packet.h| 0 > ini.cc | 4 ++ > install.cc | 11 +++- > libgetopt++/Makefile.am | 3 +- > package_db.cc | 152 > +--- > package_db.h| 3 + > package_meta.cc | 6 +- > package_meta.h | 11 +--- > prereq.cc | 1 + > res.rc | 5 +- > tree-minus.bmp | Bin > tree-plus.bmp | Bin > 24 files changed, 181 insertions(+), 49 deletions(-) > mode change 100755 => 100644 KeysSetting.cc > mode change 100755 => 100644 KeysSetting.h > mode change 100755 => 100644 crypto.cc > mode change 100755 => 100644 crypto.h > mode change 100755 => 100644 cyg-pubkey.h > mode change 100755 => 100644 cygwin.pub > mode change 100755 => 100644 gpg-packet.cc > mode change 100755 => 100644 gpg-packet.h > mode change 100755 => 100644 tree-minus.bmp > mode change 100755 => 100644 tree-plus.bmp ACK for the series with v2 of patch 8. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [PATCH setup 00/10] Various setup patches
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. > 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. >> 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. > 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. >> > 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 ;) 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 Too "boot" the CP/M clone you just have to insert a floppy with an emtpy file SCPX5105.SYS since actually it's in ROM (otherwise it starts BASIC). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [PATCH setup 00/10] Various setup patches
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 signature.asc Description: PGP signature
Re: [PATCH setup 00/10] Various setup patches
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. 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. 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 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. > 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
