[Foresight-devel] Re: FL:1 Packaging on FL:2

[Jonathan Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Cutler wrote:
| I went to work on a recent issue
| (https://issues.foresightlinux.org/browse/FL-870) last night, which is
| upgrading to a recent release of Nano.

I think, at this point, new features should only go into fl:2, which
makes the rest of this moot. But just in case you disagree...

| Is there a right way (or easy way) to package for fl:1 on a fl:2 system?

rMake, of course :)

| I thought I remembered pscott saying in IRC once you can create two
| directory structures, one for fl:1 and fl:2 and then set a context for
| each in the appropriate directory.

yes

| If I set a directory to checkout fl:1 packages, and set the context, I
| assume I still have to checkout a package using the fl:1 label?

No. If you set the buildLabel in the context, it will magically choose
the right one. Thus is the joy of contexts.

| Should (or can) a fl:2 system be building packages for fl:1?  Or
| should a packager use fl:1 in a VM to do this?

rMake

| Lastly, if I look at the howto port a package wiki page
|
(https://wiki.foresightlinux.org/display/DEV/HOWTO+port+an+application+from+Foresight+1.x+to+2.x),
| Nano 2.06 is in rpl:devel, is there a better way to backport a package
| from that to fl:1?

You should probably start with the version in rpl:devel and shadow it to
fl:1-whatever. Then make changes. Though, since fl:1 uses a new enough
libc, it *might* Just Work. We pull a number of packages directly from
rpl:devel. You'd have to have an fl:1 box to know, or you could put the
issue in "waiting for reporter" and give them a specific version (use
conary rq --full-versions nano=conary.rpath.com at rpl:devel to get a
specific version) to test.

| If anyone is up for helping me document packaging for fl:1 on a fl:2
| system (if we should be), let me know, and I'll help throw a wiki page
| together.

Meh. fl:1 is going to die Real Soon Now. IMHO, the sooner the better.
I'd kill it right this very red hot instant if moving from fl:1->2
wasn't such a pain. As soon as that is fixed, though, we should pull the
lever and kill :1.

The point is simply that the utility of that document would be limited
and probably not worth your time.

	smithj

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (GNU/Linux)

iEYEARECAAYFAkez5TcACgkQCG91qXPaRem37gCfShAt1IQImCmFxv4OFWH7ZX77
+3EAmQFeF4whbk5vHf3HTCdvKP56MTcu
=TodY
-----END PGP SIGNATURE-----