Slacker,

Some issue with new build system.

Thanks

Slackers,

Some issue with new build system.

Please check.

Thanks

Slackers,

Dependency for Slackware version 14.2 pcre2-10.32-x86_64-1_SBo.

Thanks

Slacker,

Few additions.

Please check Wiki.

Thanks

Can you please suggest the functionality (NOT code)?
I think this is issue with package naming. Two different packages (which provide different functions) uses same package name.
Thanks for reply

The problem may concern the concept of 'attitude'

From the wiki:
There is an example of different repositories with the same tag that can not be processed according to this concept:

1) alien-kde / current / latest / x86_64 / (ktown)
2) alien / sbrepos / current / x86_64 /
3) alien / restricted_sbrepos / current / x86_64 /

Another method should be used to distinguish between repos.

It may also be related to subrepo (is that the right name?) preference. alsa-only packages reside in extra/. If extra/ has a higher priority than the main repo (slackware{64}/), then the pulse packages could potentially be replaced with the alsa-only, which may not be desired by the users.

I'm not sure if this is user configurable or something hardcoded into the program (I manually manage my upgrades, so I haven't used this program).

When I say, I am less experience with Slackware. It means I have less experience with package manangement. I uses combination of packages with different repositories. I mostly use packages from Slackware official repository. Few packages from alien and rlworkman plus slackonly repository. And few compiled packages from Slackbuilds.org repository.

I have tried to handle all repositories uniform ways. I don't want to dump any repository specific code.

1. Slackonly uses _slonly
2. Rlworkman uses _rlw
3. And Slackbuild uses _SBo (default)

That is the reason I usee package tag in code to handle the repository.
And as per my knowledge It follows Slackware package naming conventions.

Am I right? Please correct

Thanks for reply

It will unnecessarily complicate the things. I want to keep the things simple.
I know that slackpkg handle such priority for sub-branches.

Insted of MPlayer-20180720-x86_64-1_alsa.txz if it like MPlayer-alsa-20180720-x86_64-1.txz, It will solve the issue.

If I am wrong then please correct...

Thanks for your suggestion.

Slackers,

Few changes.
--batch option is added.
And attitude-installer is now able to upgrade Slackware core (aaa_*) packages.

Suggestions are welcome....

Thanks

Slackers,

Few improvement.

Now upgrade-all/sys-upgrade will select kernel-generic, kernel-huge, kernel-modules, kernel-source packages for installation (insted of upgrade).

Please check....

Thanks.

Tags are good, but they can't be the only thing you use to distinguish between packages. As DaBrze mentioned, each repo can potentially have multiple packages of the same name that are designed for different things. This includes the official repo (with extra/ and testing/ -- both can be used to replace stock packages, and of course, patches/). Alien's SlackBuilds will have multiple packages for different Slackware versions, many times with the exact same name and version. And his ktown can have a current/ and testing/ for those who might be a bit more adventurous.

With the official repo, there needs to be a way to prioritize different folders. Almost all users would want patches/ preferred over slackware64/, and many may want to prefer extra/ or testing/ over the main and/or patches/ directories.

If you don't offer this type of configuration, it may make this program unusable by many Slackers.

It might complicate things, but IMO, not unnecessarily. As I mentioned above, you need to have a way to prioritize patches/ over slackware64/, and if there's packages in testing/ or extra/ that replace stock packages, people need to have a way to prioritize those over the stock packages.

Renaming those programs would then require you to blacklist all the original ones, which I don't know if you have the ability to blacklist MPlayer and not MPlayer-alsa (slackpkg doesn't currently have this in the stable and Robby has a beta version that does give this functionality).

Keep in mind, these suggestions are just from an outsider looking in since I haven't used the program.

@bassmadrigal

Thanks for reply.

I tried to follow the Slackware package naming convention while implementing the tool.
Except assigning priority to sub-branch. I will try to implement this functionality as early as possible.

But it is difficult to handle the repositories which doesn't follow the Official Slackware repository structure.
I am talking about sub-branches. And assigning same tag for different repositories.

Please suggest..

Thanks.

@bassmadrigal

I tried to follow Slackware package naming convention (like tag name) and Official Slackware repository structure.

Please Suggest.....

@slackers

Revert the last changes.

Problem with upgrade-all with new kernel: