This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]