Support a local repo to be removed on iso?

philm commented

2015-02-15 17:48:05 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Should we support a local repo in a custom pacman.conf which is copied to iso the same way xorg and lng do?

*Created by: udeved* Should we support a local repo in a custom pacman.conf which is copied to iso the same way xorg and lng do?

philm commented

2015-02-15 18:05:07 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: manjaro

Would be nice to have. Some might even use it. Not needed for our normal install medias, though.

*Created by: manjaro* Would be nice to have. Some might even use it. Not needed for our normal install medias, though.

philm commented

2015-02-15 18:25:50 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Yes, I got the idea from the thread where a user wanted to use a local repo for his custom iso.

*Created by: udeved* Yes, I got the idea from the thread where a user wanted to use a local repo for his custom iso.

philm commented

2015-02-15 18:31:05 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: manjaro

Yes, totally fine with me ...

*Created by: manjaro* Yes, totally fine with me ...

philm commented

2015-02-21 12:37:36 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

I think it would be sufficient to just remove local repo from pacman.conf if I got the request right.
As the user pointed out, he only want to use local repo to build iso, but he doesn't need this repo on the iso.

*Created by: udeved* I think it would be sufficient to just remove local repo from pacman.conf if I got the request right. As the user pointed out, he only want to use local repo to build iso, but he doesn't need this repo on the iso.

philm commented

2015-02-21 12:58:32 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

Do as needed ...

*Created by: philmmanjaro* Do as needed ...

philm commented

2015-02-21 14:35:54 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

In our forum Ste74 asked:

Community Hello ..
I do not know if I can post here this request Otherwise locate In the right section. What I state sripting as I know little or nothing, and therefore we ask You Make A script Launching the first boot (after getting installed iso Created with Manjaro-tools) to delete and replace the pacman.conf with pacman.conf original. Explain: the pacman.conf Contains my repo-Local THIS superfluous How All Programs Are Present on aur so I will not serve more the call and then I would like to eliminate ..

Thanks in advance

Seems to be right here ?!?

*Created by: philmmanjaro* In our [forum](https://forum.manjaro.org/index.php?topic=20637.0) Ste74 asked: > Community Hello .. > I do not know if I can post here this request Otherwise locate In the right section. What I state sripting as I know little or nothing, and therefore we ask You Make A script Launching the first boot (after getting installed iso Created with Manjaro-tools) to delete and replace the pacman.conf with pacman.conf original. Explain: the pacman.conf Contains my repo-Local THIS superfluous How All Programs Are Present on aur so I will not serve more the call and then I would like to eliminate .. > > Thanks in advance Seems to be right here ?!?

philm commented

2015-03-03 07:59:51 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: aadityabagga

This feature is useful for me too..

*Created by: aadityabagga* This feature is useful for me too..

philm commented

2015-05-02 14:19:12 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: aadityabagga

To solve this issue, maybe bits from geniso (discussion in forum here) could be used.

The bits that could be possibly used are:

REPOS=()

get_repos () {
  # get repos from pacman.conf specified as argument
  local pacman_conf=$1
  # sed is being used for filtering comments and repo brackets []
  REPOS=($(grep "\[*\]" "$pacman_conf" | sed -e '/^\s*#/d' -e 's/\[//' -e 's/\]//'))
}

# Get repos from pacman.conf and set valid repos
if [[ $ARCH = x86_64 ]]; then
  VALID=('options' 'core' 'extra' 'community' 'multilib')
  # Get list of repos
  if [[ -e $PROFILE/pacman-multilib.conf ]]; then
    get_repos "$PROFILE/pacman-multilib.conf"
  fi
else
  VALID=('options' 'core' 'extra' 'community')
  # Get list of repos
  if [[ -e $PROFILE/pacman-default.conf ]]; then
    get_repos "$PROFILE/pacman-default.conf"
  fi
fi

for repo in "${REPOS[@]}"
do
  if ! echo "${VALID[*]}" | grep -q "$repo"; then
    # Remove custom repo
    for file in $WORKDIR/$PROFILE/$ARCH/{livecd,root,${PROFILE%-*}}-image/etc/pacman.conf
    do
      if [[ -f $file ]] && [[ ! $QUERY = true ]]; then
        echo "Editing $file"
        sed -i "/^\[$repo/,/^Server/d" "$file" || exit 1
      fi
    done
    echo "Custom repo $repo removed from pacman.conf"
  fi
done

If deciding to go this way, maybe a flag could be added to buildiso (eg -k for keep), which could prevent the removal of specific repo(s).

This could be useful if one had two repos, one local and other remote, and wanted to remove the local repo but keep the global one.

*Created by: aadityabagga* To solve this issue, maybe bits from [geniso](https://github.com/aadityabagga/scripts/blob/master/arch-manjaro/geniso.sh) (discussion in forum [here](https://forum.manjaro.org/index.php?topic=20637.msg198256#msg198256)) could be used. The bits that could be possibly used are: ``` REPOS=() get_repos () { # get repos from pacman.conf specified as argument local pacman_conf=$1 # sed is being used for filtering comments and repo brackets [] REPOS=($(grep "\[*\]" "$pacman_conf" | sed -e '/^\s*#/d' -e 's/\[//' -e 's/\]//')) } # Get repos from pacman.conf and set valid repos if [[ $ARCH = x86_64 ]]; then VALID=('options' 'core' 'extra' 'community' 'multilib') # Get list of repos if [[ -e $PROFILE/pacman-multilib.conf ]]; then get_repos "$PROFILE/pacman-multilib.conf" fi else VALID=('options' 'core' 'extra' 'community') # Get list of repos if [[ -e $PROFILE/pacman-default.conf ]]; then get_repos "$PROFILE/pacman-default.conf" fi fi for repo in "${REPOS[@]}" do if ! echo "${VALID[*]}" | grep -q "$repo"; then # Remove custom repo for file in $WORKDIR/$PROFILE/$ARCH/{livecd,root,${PROFILE%-*}}-image/etc/pacman.conf do if [[ -f $file ]] && [[ ! $QUERY = true ]]; then echo "Editing $file" sed -i "/^\[$repo/,/^Server/d" "$file" || exit 1 fi done echo "Custom repo $repo removed from pacman.conf" fi done ``` If deciding to go this way, maybe a flag could be added to buildiso (eg -k for keep), which could prevent the removal of specific repo(s). This could be useful if one had two repos, one local and other remote, and wanted to remove the local repo but keep the global one.

philm commented

2015-05-02 21:14:47 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: aadityabagga

After some hours of work, was able to integrate it.
Its contained in pull request https://github.com/manjaro/manjaro-tools/pull/87

*Created by: aadityabagga* After some hours of work, was able to integrate it. Its contained in pull request https://github.com/manjaro/manjaro-tools/pull/87

philm commented

2015-05-08 10:56:01 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

I don't quite get the point of configuring xorg & lng cache cleaning in the conf file.

Makes the switches kind of useless. Is this tested properly if switches are used and conf set?

*Created by: udeved* I don't quite get the point of configuring xorg & lng cache cleaning in the conf file. Makes the switches kind of useless. Is this tested properly if switches are used and conf set?

philm commented

2015-05-08 14:08:22 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: aadityabagga

Hi udeved,

I had accidentally commited my changes about cleaning pacman.conf and trimming xorg cache leading to a little confusion; I will try to explain.

Regarding Xorg and lng cache, what we had earlier was that the whole cache would get copied to the ISO, ie, if there were multiple versions of the same package, they would get copied. I thought to make it like pacman cache, which only copies the latest version, and sent a pull request that trims copied pacman cache.

With this change, now one does not need to clean Xorg and lng cache always, so I introduced an option for not cleaning it by default in the config.

I agree with you that it makes the switches kind of redundant and you could remove them if you feel its appropriate.

*Created by: aadityabagga* Hi udeved, I had accidentally commited my changes about cleaning pacman.conf and trimming xorg cache leading to a little confusion; I will try to explain. Regarding Xorg and lng cache, what we had earlier was that the whole cache would get copied to the ISO, ie, if there were multiple versions of the same package, they would get copied. I thought to make it like pacman cache, which only copies the latest version, and sent a [pull request](https://github.com/manjaro/manjaro-tools/pull/85) that trims copied pacman cache. With this change, now one does not need to clean Xorg and lng cache always, so I introduced an option for not cleaning it by default in the config. I agree with you that it makes the switches kind of redundant and you could remove them if you feel its appropriate.

philm commented

2015-05-08 14:38:17 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Hmm, I would rather remove file based switches in favour of cli switches.
I personally don't like bool switches in a config.
I only use xorg cache enabled if I rebuild a test build immediately.

*Created by: udeved* Hmm, I would rather remove file based switches in favour of cli switches. I personally don't like bool switches in a config. I only use xorg cache enabled if I rebuild a test build immediately.

philm commented

2015-05-08 14:52:09 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: aadityabagga

Yup, that is why I added an option in config, some people want to clean every time, some do not want to :-)

If it was a switch one of the parties could feel inconvenienced as they would have to add -x every time, this way one can set it in config and only change when required.

This discussion gives me an idea: maybe the -x or -l switches could be made as toggles, ie, if in config it is specified to clean, and -x option is specified, then dont clean.

Alternatively, if it is specified in config to not clean, and -x is supplied, then clean.

This discussion can be more relevant in the following issue I think: https://github.com/manjaro/manjaro-tools/issues/86
Or we could open a new one.

*Created by: aadityabagga* Yup, that is why I added an option in config, some people want to clean every time, some do not want to :-) If it was a switch one of the parties could feel inconvenienced as they would have to add -x every time, this way one can set it in config and only change when required. This discussion gives me an idea: maybe the -x or -l switches could be made as toggles, ie, if in config it is specified to clean, and -x option is specified, then dont clean. Alternatively, if it is specified in config to not clean, and -x is supplied, then clean. This discussion can be more relevant in the following issue I think: https://github.com/manjaro/manjaro-tools/issues/86 Or we could open a new one.

philm commented

2015-05-08 14:59:48 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Everything else is fine, but the switches in the config will likely go. The reason is, if we start with switches in a file, we will accumulate more and more switches in the config over time, I would like to avoid this.
A cli program will always make use of cli switches for special cases, such as activating the xorg cache.
Except you can guarantee that always using xorg cache works without any complications, then we can remove the -x flag altogether from config and cli, so its always used.

*Created by: udeved* Everything else is fine, but the switches in the config will likely go. The reason is, if we start with switches in a file, we will accumulate more and more switches in the config over time, I would like to avoid this. A cli program will always make use of cli switches for special cases, such as activating the xorg cache. Except you can guarantee that always using xorg cache works without any complications, then we can remove the -x flag altogether from config and cli, so its always used.

philm commented

2015-05-08 15:09:23 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: aadityabagga

Maybe the behaviour of the switches could be reversed then, like using -x and -l will clean, default will be to not clean?

*Created by: aadityabagga* Maybe the behaviour of the switches could be reversed then, like using -x and -l will clean, default will be to not clean?

philm commented

2015-05-08 15:16:17 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Whats the point of having switches if the cache handles different versions?
I think, if the cache works as you intended, we can remove those cache switches altogether.
I never liked them much, but the request was to have a cache.
If your solution works, lets remove the switches, they are kind of useless then. :)

*Created by: udeved* Whats the point of having switches if the cache handles different versions? I think, if the cache works as you intended, we can remove those cache switches altogether. I never liked them much, but the request was to have a cache. If your solution works, lets remove the switches, they are kind of useless then. :)

philm commented

2015-05-08 15:26:24 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: aadityabagga

The advantage with keeping the switches and reversing their behaviour will be that when cache gets too big, they can be used to clean it.

Also, when releasing (final) ISOs, they can be used as a precaution to ensure that no extra/old packages get added (ie, clean build).

But it is upto you, you can remove them if they feel redundant :-)

*Created by: aadityabagga* The advantage with keeping the switches and reversing their behaviour will be that when cache gets too big, they can be used to clean it. Also, when releasing (final) ISOs, they can be used as a precaution to ensure that no extra/old packages get added (ie, clean build). But it is upto you, you can remove them if they feel redundant :-)

philm commented

2015-05-08 15:30:16 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: philmmanjaro

Let us do a test run. I know that @aadityabagga uses the tools differently as we do. By default our old behavior is still present.

*Created by: philmmanjaro* Let us do a test run. I know that @aadityabagga uses the tools differently as we do. By default our old behavior is still present.

philm commented

2015-05-10 19:43:00 +00:00

(Migrated from gitlab2.manjaro.org)

Created by: udeved

Ok, I have added some code regarding removing a custom local repo.
It parses custom pacman.conf if present, and removes any custom repo having a local filesystem('file://') address.
No keep_repos var though, all done with parsing, custom remote repos are kept.

==> Done [Base installation] (root-image)
  -> is_custom_pac_conf: true
  -> repo: openrc-eudev
  -> repo: my-repo
  -> Removing custom local repo my-repo ...

See github.com/manjaro/manjaro-tools@775345c0db

*Created by: udeved* Ok, I have added some code regarding removing a custom local repo. It parses custom pacman.conf if present, and removes any custom repo having a local filesystem('file://') address. No keep_repos var though, all done with parsing, custom remote repos are kept. ``` ==> Done [Base installation] (root-image) -> is_custom_pac_conf: true -> repo: openrc-eudev -> repo: my-repo -> Removing custom local repo my-repo ... ``` See https://github.com/manjaro/manjaro-tools/commit/775345c0dbd400d572d0cf61ea721443c185b9f0

Rows
Columns

Support a local repo to be removed on iso? #54