wiki: Converting Gentoo page recommends invalid procedure

[maxcrees]

git clone git@github.com:Galapagos-Linux/main /usr/portage will fail for users who do not have access rights to this repository. Recommend replacing it with git clone git://github.com/Galapagos-Linux/main.git /usr/portage.

[maxcrees]

In addition, the /usr/local/portage/metadata/layout.conf file may also need to be changed to read masters = galapagos.

[maxcrees]

This repo also does not include any of the necessary metadata files (md5-cache) to be used as a sync repository. This can be generated with

wget -O /usr/portage/metadata/xml-schema/metadata.xsd https://gitweb.gentoo.org/repo/sync/gentoo.git/plain/metadata/xml-schema/metadata.xsd
egencache --repo galapagos --update
egencache --repo galapagos --update-pkg-desc-index
egencache --repo galapagos --update-use-local-desc

but this is only a temporary solution (not sure if it's even exhaustive since I'm currently in the process of doing it) and shouldn't have to be done by the user.

[idella]

Sure also:

• Portage folder I would prefer to be an entirely different name, such as gumtree. It is an entirely arbitrary 'string', but the rationale is simple. Portage is the package manager and not the collection of packages in a repo

• /usr/portage is also arbitrary. I shifted the folder /portage out of /usr years ago. The fundamental principle in ebuild writing is to write it generically so it will work in any system, so the use of vars lends itself to this outcome: TREENAME="..."; PORTDIR=""; The coded destinations then become "${PORTDIR}" && "${TREENAME}"

Think of this is fine refinement.

[mjeveritt]

• Portage folder I would prefer to be an entirely different name, such as gumtree. It is an entirely arbitrary 'string', but the rationale is simple. Postage is the package manager and not the collection of packages in a repo

This is an interesting idea. There has been a lot of confusion about what portage refers to, but I would be concerned about edge cases of breakage by changing this. Sure, most of the time setting everything up right will be fine, but where -could- it potentially go wrong. Also, how does paludis and the other package managers work .. do they have a /usr/paludis for example?

• /usr/portage is also arbitrary. I shifted the folder /portage out of /usr years ago. The fundamental principle in ebuild writing is to write it generically so it will work in any system, so the use of vars lends itself to this outcome: TREENAME="..."; PORTDIR=""; The coded destinations then become "${PORTDIR}" && "${TREENAME}"

I have symlinked my /usr/portage to /var/portage to allow it to exist on a spinning rust drive rather than my SSD because of the likelihood of frequent updates. I do reiterate 'symlinked', whilst I know that there are Portage variables to set this location, I do believe I've been caught out before by things not ending up where they should do. Again, what are the edge cases here, and what do other package managers expect? Think of this is fine refinement.

I think its a reasonable idea, just worried more about implementation details. There is no particular requirement to follow upstream here, but we could be creating a lot of problems for ourselves if we have to continuously patch in order to continue to accept upstream updates!

[idella]

concerned about edge cases of breakage by changing this

we are or at least I am a developer. Your time will come if you make a learning contract and gety upgraded. Developers take the challenge, set up a testing environment and put it through its paces.

but where -could- it potentially go wrong.

Testing will reveal it and if it doesn't, someone will trip over what 'we' missed and make a bug over it, which is normal procedure. The anticipation of a disaster is of course a worthy exercise to ponder, so ponder it we can. Let the show begin.

Also, how does paludis and the other package managers work

I neither know nor care. The P.M. of galapagos will be portage and portage only. To be obliged to account for a paludis would afaiac beckon a 'motion' to ban any support of paludis or pkg-core and cater purely to portage. Gentoo itself is far too stretched to cover all bases. There is NO need for galapagos to experience either shame or guilt for covering options or functionality beyond its means. Choice as an ideal is nice, but if the cost too high and unachievable, DROP IT.

afa the final point is concerned,

I do believe I've been caught out before by things

please share the pain and we can include the data in testing so as to cover and cure. That is what developers do.

[maxcrees]

Getting (relatively) back on topic, there currently is no news dissemination, although whether the repository will transmit only Gentoo news, only Galapagos news, or both is unclear.

If you're using eix, I recommend using eix-sync over emerge --sync for now with the following /etc/eix-sync.conf:

@egencache --repo=galapagos --update
@egencache --repo=galapagos --update-pkg-desc-index
@egencache --repo=galapagos --update-use-local-desc

--jobs=N can also be added as appropriate.